Как, если вообще, Процессы Erlang отображаются на Потоки ядра?
Фейсбук как кнопка делает две вещи, которые API не делает. Это может создать путаницу при сравнении этих двух.
- Если URL-адрес, который вы используете в своей кнопке, имеет перенаправление, кнопка фактически отображает счет URL-адреса переадресации по сравнению с количеством URL-адреса, которое вы используются.
- Если страница имеет свойство og: url, то подобная кнопка будет отображать подобные url вместо url в браузере.
Надеюсь, это поможет кому-то
3 ответа
Ответ зависит от VM, который используется:
1) не-SMP : существует один планировщик (поток ОС), который выполняет все процессы Erlang, взятые от пул выполнимых процессов (т.е. те, кто не заблокирован, например, receive)
2) SMP: существуют планировщики K (потоки ОС, K обычно является многими ядрами процессора), который выполняет процессы Erlang от совместно использованная очередь процесса . Это - простая очередь FIFO (с блокировками для предоставления одновременного доступа от нескольких потоков ОС).
3) SMP в R13B и более новый : будет планировщики K (как прежде), который выполняет процессы Erlang от [1 116] несколько очередей процесса . Каждый планировщик имеет свою собственную очередь, так процесс , логика миграции от одного планировщика до другого будет добавлена. Это решение улучшит производительность путем предотвращения чрезмерной привязки совместно использованная очередь процесса.
Для получения дополнительной информации см. этот документ , подготовленный Kenneth Lundin, Ericsson AB, для Конференции пользователей Erlang, Стокгольма, 13 ноября 2008.
Я просто предполагаю здесь, но я предположил бы, что существует небольшое количество потоков, которые выбирают процессы от общего пула процесса для выполнения. Как только процесс поражает операцию блокирования, поток, выполняющий его, откладывает его и выбирает другого. Когда процесс, выполняемый причины другой процесс для становления разблокированным, который недавно разблокировал процесс, помещается в пул. Я предполагаю, что поток мог бы также остановить выполнение процесса, даже когда это не заблокировано в определенные моменты для обслуживания других процессов.
I want to ammend previous answers.
Erlang, or rather the Erlang runtime system (erts), defaults the number of schedulers (OS threads) and the number of runqueues to number of processing elements on your platform. That is processors cores or hardware threads. You can change these settings in runtime using:
erlang:system_flag(schedulers_online, NP) -> PrevNP
The Erlang processes does not have any affinity to any schedulers yet. The logic balancing the processes between the schedulers follows two rules. 1) A starving scheduler will steal work from another scheduler. 2) Migration paths are setup to push processes from schedulers with lots of processes to schedulers with less work. This is done to assure fairness in reduction count (execution time) for each process.
Schedulers however can be locked to specific processing elements. This not done by default. To let erts do the scheduler->core affinity use:
erlang:system_flag(scheduler_bind_type, default_bind) -> PrevBind
Several other bind types can be found in the documentation. Using affinity can greatly improve performance in heavy load situations! Especially in high lock contention situations. Also, the linux kernel cannot handle hyperthreads to say the least. If you have hyperthreads on your platform you should really use this feature in erlang.