Erlang: блокировка поведения вызова C NIF

Я думаю, что ответы о долго работающих NIF не соответствуют действительности, поскольку в вашем вопросе говорится, что вы используете какой-то простой код «hello world» и спите всего 100 человек. Это правда, что в идеале вызов NIF не должен занимать более миллисекунды, но ваши NIF, скорее всего, не вызовут проблем с планировщиком, если только они не выполняются последовательно в течение десятков миллисекунд за раз или более.

У меня есть простой NIF с именем rev/1, который принимает строковый аргумент, переворачивает его и возвращает перевернутую строку. Я вставил вызов usleep в его середину, а затем создал 100 одновременных процессов Erlang для его вызова. Две трассировки стека потоков, показанные ниже, основанные на Erlang/OTP 17.3.2, показывают два потока планировщика Erlang внутри rev/1 NIF одновременно, один в точке останова, которую я установил в самой функции NIF C, другой заблокирован в usleep внутри NIF. :

Thread 18 (process 26016):
#0  rev (env=0x1050d0a50, argc=1, argv=0x102ecc340) at nt2.c:9
#1  0x000000010020f13d in process_main () at beam/beam_emu.c:3525
#2  0x00000001000d5b2f in sched_thread_func (vesdp=0x102829040) at beam/erl_process.c:7719
#3  a0x0000000100301e94 in thr_wrapper (vtwd=0x7fff5fbff068) at pthread/ethread.c:106
#4  0x00007fff8a106899 in _pthread_body ()
#5  0x00007fff8a10672a in _pthread_start ()
#6  0x00007fff8a10afc9 in thread_start ()

Thread 17 (process 26016):
#0  0x00007fff8a0fda3a in __semwait_signal ()
#1  0x00007fff8d205dc0 in nanosleep ()
#2  0x00007fff8d205cb2 in usleep ()
#3  0x000000010062ee65 in rev (env=0x104fcba50, argc=1, argv=0x102ec8280) at nt2.c:21
#4  0x000000010020f13d in process_main () at beam/beam_emu.c:3525
#5  0x00000001000d5b2f in sched_thread_func (vesdp=0x10281ed80) at beam/erl_process.c:7719
#6  0x0000000100301e94 in thr_wrapper (vtwd=0x7fff5fbff068) at pthread/ethread.c:106
#7  0x00007fff8a106899 in _pthread_body ()
#8  0x00007fff8a10672a in _pthread_start ()
#9  0x00007fff8a10afc9 in thread_start ()

Если бы в эмуляторе Erlang были какие-либо мьютексы, препятствующие одновременному доступу к NIF, трассировки стека не отображали бы оба потока внутри C NIF.

Было бы неплохо, если бы вы опубликовали свой код, чтобы те, кто хочет помочь решить эту проблему, могли видеть, что вы делаете, и, возможно, помочь вам найти любые узкие места. Также было бы полезно, если бы вы сообщили нам, какие версии Erlang/OTP вы используете.

Сами NIF не имеют мьютексов. Вы можете реализовать один на C, и один при загрузке объекта NIF, но это нужно сделать только один раз с загрузочным модулем.

Одна вещь, которая может произойти (и я держу пари, что это то, что происходит), это то, что ваш код C портит планировщик(и) Erlang.

Собственная функция, которая выполняет длительную работу перед возвратом, ухудшит реакцию виртуальной машины и может вызвать странное поведение. Такое странное поведение включает, помимо прочего, чрезмерное использование памяти и неправильную балансировку нагрузки между планировщиками. Странное поведение, которое может возникнуть из-за длительной работы, также может варьироваться в зависимости от выпуска OTP.

и описание того, что означает lengty work и как вы можете решить эту проблему.

В двух словах (с небольшими упрощениями):

Для ядра создан один планировщик. У каждого есть список процессов, которые он может запускать. Если его список планировщика пуст, он попытается продолжить работу с другого. Это может потерпеть неудачу, если нечего (или недостаточно) еще.

Планировщики Erlang тратят какое-то количество работы в одном процессе, затем перемещаются в другой, тратят там какое-то количество работы и переходят в другое. И так далее, и так далее. Это очень похоже на планирование в системных процессах.

Здесь очень важно рассчитать объем работы. По умолчанию каждому вызову функции назначено некоторое количество сокращений. У дополнения может быть два, у вызывающей функции в вашем модуле будет один, у отправки сообщения также один, у некоторых встроенных может быть больше (например, list_to_binary). Если мы набираем 2 000 сокращений, мы переходим к другому процессу.

Итак, какова стоимость вашей C-функции? Это только одно сокращение.

Код как

loop() ->
   call_nif_function(),
   loop().

может занять целый час, но планировщик застрянет на этом одном процессе, потому что он еще не досчитал до 2 000 сокращений. Или, другими словами, он может застрять внутри НИФ без возможности двигаться вперед (по крайней мере, в ближайшее время).

Есть несколько способов обойти это, но общее правило таково: много времени. Поэтому, если у вас есть длинный код C, возможно, вам следует использовать драйверы. Их должно быть намного проще реализовать и управлять ими, чем возиться с NIF.

Вызовы NIF блокируют планировщик, к которому привязан вызвавший их процесс. Итак, для вашего примера, если эти другие процессы находятся в том же планировщике, они не могут вызывать NIF, пока не завершится первый процесс.

В этом отношении вы не можете сделать вызов NIF неблокирующим. Однако вы можете создавать свои собственные потоки и перекладывать на них основную тяжесть своей работы.

Такие потоки могут отправлять сообщения локальным процессам Erlang (процессам на том же компьютере), и поэтому вы все равно можете получить желаемый ответ, ожидая, пока созданный вами поток отправит обратно сообщение.

Плохой пример:

static ERL_NIF_TERM my_function(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) {
    MyStruct* args = new MyStruct(); // I like C++; so sue me
    args->caller = enif_self();
    ErlNifTid thread_id;
    // Please remember, you must at some point rejoin the thread, 
    // so keep track of the thread_id
    enif_thread_create("my_function_thread", &thread_id, my_worker_function, (void*)args, NULL);
    return enif_make_atom(env, "ok");
}
void* my_worker_function(void* args) {
    sleep(100);
    ErlNifEnv* msg_env = enif_alloc_env();
    ERL_NIF_TERM msg = enif_make_atom(msg_env, "ok");
    enif_send(NULL, args->caller, msg_env, msg);
    delete args;
    return NULL;
}

И в вашем источнике erlang:

test_nif() -> 
    my_nif:my_function(),
    receive
        ok -> ok
    end.

Во всяком случае, что-то в этом роде.