Как, если вообще, делаются ли процессы Erlang Process to Kernel Threads?

Question

Erlang известен тем, что способен поддерживать МНОГИЕ легкие процессы; он может это сделать, потому что это не процессы в традиционном смысле, или даже потоки, как в P-потоках, но потоки полностью в пространстве пользователя.

Это хорошо и хорошо (фантастически на самом деле). Но как же тогда потоки Erlang выполняются параллельно в многоядерной/многопроцессорной среде? Разумеется, они должны каким-то образом сопоставляться с потоками ядра для выполнения на отдельных ядрах?

Предполагая, что это так, как это делается? Являются ли многие легкие процессы сопоставлены с одним потоком ядра?

Или есть другой способ решения этой проблемы?

Answer 1

Ответ зависит от VM, которая используется:

1) не-SMP: Существует один планировщик (OS нити), которая выполняет все процессы Erlang, взятый из пула запускаемых процессов (т.е. те, которые не блокируются, например receive)

2) SMP: есть К планировщики (потоки ОС, К, как правило, количество ядер процессора), который выполняет Erlang процессов из общей очереди процессов . Это простая очередь FIFO (с блокировками для одновременного доступа из нескольких потоков ОС).

3) СМП в R13B и новые: Там будет К планировщики (как раньше), который выполняет процессы Erlang из нескольких очередей процесса. Каждый планировщик имеет свою собственную очередь, поэтому будет добавлен процесс логики миграции от одного планировщика к другому. Это решение повысит производительность, избегая чрезмерной блокировки в очереди общих процессов.

Для получения дополнительной информации см this document подготовленного Кеннет Лундином, Ericsson AB, для конференции Erlang пользователя, Стокгольма, 13 ноября 2008 года

Answer 2

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

Answer 3

Я хочу ammend предыдущих ответов.

Эрланг, или, скорее, система времени выполнения Erlang (erts), по умолчанию задает количество планировщиков (потоки ОС) и количество строк в количестве обрабатываемых элементов на вашей платформе. Это процессорные ядра или аппаратные потоки. Вы можете изменить эти настройки во время выполнения с помощью:

erlang:system_flag(schedulers_online, NP) -> PrevNP 

Процессы Erlang не имеют сродства к любым планировщикам еще. Логическая балансировка процессов между планировщиками выполняется по двум правилам. 1) Голодный планировщик будет украсть работу у другого планировщика. 2) Пути миграции настраиваются для толкания процессов от планировщиков с большим количеством процессов для планировщиков с меньшими затратами.Это делается для обеспечения справедливости в количестве сокращений (времени выполнения) для каждого процесса.

Планировщики, однако, могут быть заблокированы для конкретных элементов обработки. Это не сделано по умолчанию. Для того, чтобы сделать ГЭР scheduler-> основного использования сродства:

erlang:system_flag(scheduler_bind_type, default_bind) -> PrevBind 

Несколько других типов связывания можно найти в документации. Использование аффинности может значительно повысить производительность при тяжелых нагрузках! Особенно в ситуациях с высокой степенью блокировки. Кроме того, ядро ​​Linux не может обрабатывать гиперпотоки, если не сказать больше. Если у вас гипертексты на вашей платформе, вы действительно должны использовать эту функцию в erlang.

Answer 4

Я хотел бы добавить некоторый вклад в то, что было описано в принятом ответе.

Планировщик Erlang является неотъемлемой частью Runtime System Erlang и обеспечивает собственную абстракцию и реализацию концепции легких процессов поверх потоков ОС.

Каждый планировщик работает в одном потоке ОС. Как правило, столько же планировщиков, сколько процессор (ядра) находятся на оборудовании (он настраивается и, естественно, не приносит большого значения, когда количество планировщиков превышает количество аппаратных ядер). Система также может быть настроена так, что планировщик не будет переходить между потоками ОС.

Теперь, когда процесс Erlang создается это полностью ответственность ГЭР и планировщик для управления жизненным циклом и потребления ресурсов, а также ее объем памяти и т.д.

Одним из основных деталей реализации является то, что каждый процесс имеет временный бюджет сокращений 2000, доступных, когда Планировщик берет этот процесс из очереди выполнения. Каждый прогресс в системе (даже I/O) гарантированно будет иметь бюджет сокращения. Именно это делает ERTS системой с упреждающей многозадачностью.

Я рекомендовал бы большой пост в блоге на эту тему по Jesper Andersen Луи http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-scheduling.html

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