Какие потоки ОС используются в абстрактной машине Эрланга, BEAM?

Question

Я начал изучать Erlang и нахожу среду исполнения BEAM увлекательной.Обычно утверждается, что в Erlang процессы принадлежат языку, а не ОС (имеется в виду время выполнения, в данном случае означает BEAM).Это легкие, «зеленые процессы», которыми Эрланг становится известным.Далее указано (на странице 5 этой статьи ), что BEAM использует один (1) поток ОС на ядро ​​ЦП для планирования, а другой поток ОС - для ввода-вывода.Итак, мне интересно: Из какого потока берутся циклы ЦП, необходимые для фактического выполнения кода Эрланга?

Кроме того, если бы я работал на двухъядерной машине, я бы ожидал - основываясь на том,Прочтите до сих пор - чтобы увидеть три (3) потока, работающих в процессе BEAM: два планировщика (по одному на каждое ядро) и один поток ввода-вывода.Но я вижу 10. Иногда 11. Иногда он начинается с 13, и, как высококачественные усилители, идет до 11.

Я в замешательстве.Любое понимание будет оценено.

Answer 1

Следуя совету @ user425720, я задал свой вопрос по erlang-questions LISTSERV.Он также доступен как Группа Google .Крестен Краб Торуп из Трифорка ответил мне почти сразу.Спасибо, что вышли на Крестон.Вот его ответ.(Круглые скобки и акценты мои.)

Вот базовый сценарий AFAIK:

Erlang-код будет выполняться в таком количестве «зеленых потоков», сколько существует процессов;предел процесса контролируется флагом + P (командная строка).

Зеленые потоки отображаются на S потоков, где S - количество ядер / процессоров.Тот факт, что эти потоки также называются планировщиками , может показаться странным, но с точки зрения виртуальных машин это так. С точки зрения разработчика, они являются потоками, которые запускают ваш код erlang .Число S можно контролировать с помощью опции + S в командной строке erl.

Кроме того, существует ряд так называемых «асинхронных потоков».Это пул потоков, который используется процессами ввода-вывода, называемыми связанными в драйверах, чтобы реагировать на выбор / опрос и т. Д. Число асинхронных потоков является динамическим, но ограничено флагом + A.

Итак, 11 потоков, которые вы видите на двухъядерном процессоре, могут быть 2 планировщиками и 9 асинхронными потоками.Например.

Подробнее о флагах здесь .

Answer 2

Процессы Erlang не являются «зелеными», так как потоки зелены в Java. Процессы Erlang - это структуры, которые не разделяют память и поддерживаются Erlang VM.

Может показаться странным, но этот документ может быть «старым» (хотя биография 2007 года). Все изменилось к выпуску R13, когда мы получили совершенно новую обработку очередей времени выполнения (с динамической балансировкой и другими вкусностями). Вот некоторая презентация Ульфа Вигера об этом http://ulf.wiger.net/weblog/2009/01/23/erlang-programming-for-multicore/

Подводя итог, можно сказать, что процессы полностью прозрачны, и вы можете настроить количество очередей и планировщиков времени выполнения, но реализация ОС не повреждена. Я не хочу спекулировать, почему существует как 11 потоков ..

РЕДАКТИРОВАТЬ: Я немного ошибаюсь с ОС:

+S Schedulers:SchedulerOnline

Устанавливает количество потоков планировщика для создания и потоков планировщика, чтобы установить онлайн, когда включена поддержка SMP.

Допустимый диапазон для обоих значений: 1-1024. Если система времени исполнения Erlang способна определить количество настроенных логических процессоров и доступных логических процессоров, по умолчанию для планировщиков будут настроены логические процессоры, а для SchedulersOnline по умолчанию будут доступны логические процессоры; в противном случае значения по умолчанию будут 1. Планировщики могут быть опущены, если :SchedulerOnline нет, и наоборот. Количество онлайн-планировщиков может быть изменено во время выполнения с помощью erlang:system_flag(schedulers_online, SchedulersOnline).

...

Этот флаг будет игнорироваться, если в эмуляторе не включена поддержка SMP (см. Флаг -smp).

отсюда: http://www.erlang.org/doc/man/erl.html

РЕДАКТИРОВАТЬ 2: Интересное обсуждение списка рассылки вопросов об Эрланге о плюсах и минусах многих виртуальных машин против многих планировщиков. К сожалению, это также с 2008 года и может быть недействительным с огромными улучшениями в новых выпусках OTP. http://www.erlang.org/cgi-bin/ezmlm-cgi?4:mss:38165:200809:nbihpkepgjcfnffkoobf