¿Cómo, si es que lo hace, los procesos de Erlang se asignan a hilos de kernel?

Question

Erlang es conocido por ser capaz de soportar MUCHOS procesos ligeros; puede hacer esto porque estos no son procesos en el sentido tradicional, o incluso hilos como en hilos P, sino hilos enteramente en el espacio del usuario.

Esto está muy bien (fantástico en realidad). Pero, ¿cómo se ejecutan los hilos Erlang en paralelo en un entorno multinúcleo / multiprocesador? ¿Seguramente tienen que ser mapeados de algún modo a los hilos del núcleo para poder ejecutarse en núcleos separados?

Suponiendo que ese sea el caso, ¿cómo se hace esto? ¿Hay muchos procesos ligeros asignados a un solo hilo del núcleo?

¿O hay otra forma de evitar este problema?

Answer 1

La respuesta depende de la VM que se use:

1) no SMP : hay un planificador (hilo del sistema operativo), que ejecuta todos los procesos de Erlang, tomados del grupo de procesos ejecutables (es decir, aquellos que no están bloqueados, por ejemplo, recibir )

2) SMP : hay K programadores (subprocesos del sistema operativo, K suele ser un número de núcleos de CPU), que ejecuta procesos Erlang desde el proceso compartido cola . Es una cola FIFO simple (con bloqueos para permitir el acceso simultáneo desde múltiples hilos del sistema operativo).

3) SMP en R13B y posteriores : Habrá K programadores (como antes) que ejecutan procesos Erlang desde colas de procesos múltiples . Cada programador tiene su propia cola, por lo que se agregará el proceso lógica de migración de un programador a otro. Esta solución mejorará el rendimiento al evitar el bloqueo excesivo en la cola de procesos compartidos.

Para obtener más información, consulte este documento preparado por Kenneth Lundin, Ericsson AB, para Erlang User Conference, Estocolmo, 13 de noviembre de 2008.

Answer 2

Quiero enmendar respuestas anteriores.

Erlang, o más bien el sistema de tiempo de ejecución de Erlang (erts), el número predeterminado de planificadores (subprocesos del sistema operativo) y el número de colas de ejecución a la cantidad de elementos de procesamiento en su plataforma. Es decir, núcleos de procesadores o hilos de hardware. Puede cambiar esta configuración en tiempo de ejecución usando:

erlang:system_flag(schedulers_online, NP) -> PrevNP

Los procesos de Erlang todavía no tienen afinidad con ningún planificador. La lógica que equilibra los procesos entre los planificadores sigue dos reglas. 1) Un planificador muerto de hambre robará el trabajo de otro planificador. 2) Las rutas de migración se configuran para impulsar procesos desde planificadores con muchos procesos a planificadores con menos trabajo. Esto se hace para garantizar la equidad en el recuento de reducción (tiempo de ejecución) para cada proceso.

Sin embargo, los programadores

pueden bloquearse a elementos de procesamiento específicos. Esto no se hace por defecto. Para permitir que erts haga el planificador- > uso de afinidad principal:

erlang:system_flag(scheduler_bind_type, default_bind) -> PrevBind

Se pueden encontrar varios otros tipos de enlace en la documentación. ¡Usar afinidad puede mejorar enormemente el rendimiento en situaciones de carga pesada! Especialmente en situaciones de alta contención de bloqueo. Además, el kernel de Linux no puede manejar hyperthreads por decir lo menos. Si tiene hyperthreads en su plataforma, realmente debería usar esta función en erlang.

Answer 3

Estoy simplemente adivinando aquí, pero me imagino que hay una pequeña cantidad de subprocesos, que seleccionan procesos de un grupo de procesos común para su ejecución. Una vez que un proceso llega a una operación de bloqueo, el subproceso que lo ejecuta lo deja a un lado y elige otro. Cuando un proceso que se ejecuta hace que otro proceso se desbloquee, ese proceso recién desbloqueado se coloca en el grupo. Supongo que un hilo también puede detener la ejecución de un proceso incluso cuando no está bloqueado en ciertos puntos para servir a otros procesos.

Answer 4

Me gustaría agregar alguna entrada a lo que se describió en la respuesta aceptada.

Erlang Scheduler es la parte esencial del Sistema Erlang Runtime y proporciona su propia abstracción e implementación de la concepción de procesos livianos sobre los hilos del sistema operativo.

Cada programador se ejecuta dentro de un único hilo del sistema operativo. Normalmente, hay tantos programadores como CPU (núcleos) en el hardware (aunque es configurable y, naturalmente, no aporta mucho valor cuando el número de programadores excede los de los núcleos de hardware). El sistema también podría estar configurado para que el planificador no salte entre los hilos del sistema operativo.

Ahora, cuando se crea el proceso Erlang, es responsabilidad exclusiva del ERTS y el Programador gestionar el ciclo de vida y el consumo de recursos, así como su huella de memoria, etc.

Uno de los detalles básicos de implementación es que cada proceso tiene un presupuesto de tiempo de 2000 reducciones disponibles cuando el Programador recoge ese proceso de la cola de ejecución. Se garantiza que cada progreso en el sistema (incluso E / S) tendrá un presupuesto de reducciones. Eso es lo que hace que ERTS sea un sistema con multitarea preventiva.

Recomendaría una gran publicación de blog sobre ese tema por Jesper Louis Andersen http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-scheduling.html

Como respuesta corta: los procesos de Erlang no son subprocesos del sistema operativo y no se asignan directamente a ellos. Los programadores Erlang son los que se ejecutan en los subprocesos del sistema operativo y proporcionan una implementación inteligente de procesos Erlang más finos que ocultan esos detalles detrás de los ojos del programador.