¿Cómo, en todo caso, los Procesos de Erlang se asignan a Kernel Threads?

Question

Erlang es conocido por ser capaz de soportar MUCHOS procesos livianos; puede hacerlo porque no se trata de procesos en el sentido tradicional, o incluso de subprocesos como en P-hilos, sino que se trata por completo de hilos en el espacio de usuario.

Esto está muy bien (fantástico en realidad). ¿Pero cómo se ejecutan los subprocesos Erlang en paralelo en un entorno multinúcleo/multiprocesador? ¿Seguramente tienen que mapearse de alguna manera a los hilos del kernel para poder ser ejecutados en núcleos separados?

Suponiendo que ese sea el caso, ¿cómo se hace esto? ¿Hay muchos procesos livianos mapeados en un solo hilo del kernel?

¿O hay otra forma de solucionar este problema?

Answer 1

respuesta depende de la máquina virtual que se utiliza:

1) sin SMP: Hay un planificador (hebra de OS), que ejecuta todos los procesos de Erlang, tomada de la piscina de procesos ejecutables (es decir, aquellos que no están bloqueadas por ejemplo receive)

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

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

Para más información ver this document preparado por Kenneth Lundin, Ericsson AB, para la Conferencia de Erlang usuario, Estocolmo, 13 de noviembre de 2008.

Answer 2

Estoy adivinando aquí, pero me imagino que hay un pequeño número de subprocesos, que eligen 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 hilo que lo ejecuta lo deja de lado y elige otro. Cuando un proceso que se está ejecutando causa que otro proceso se desbloquee, el 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 3

Quiero ammend respuestas anteriores.

Erlang, o más bien el sistema de tiempo de ejecución Erlang (erts), predetermina el número de programadores (subprocesos del sistema operativo) y el número de runqueues a la cantidad de elementos de procesamiento en su plataforma. Eso son núcleos de procesadores o hilos de hardware. Puede cambiar estos parámetros en tiempo de ejecución usando:

erlang:system_flag(schedulers_online, NP) -> PrevNP 

Los procesos Erlang no tiene afinidad con cualquier programadores todavía. La lógica que equilibra los procesos entre los programadores sigue dos reglas. 1) Un programador hambriento robará trabajo de otro planificador. 2) Las rutas de migración están configuradas para enviar procesos de programadores con muchos procesos a planificadores con menos trabajo.Esto se hace para asegurar la equidad en el conteo de reducción (tiempo de ejecución) para cada proceso.

Los programadores, sin embargo, se pueden bloquear con elementos de procesamiento específicos. Esto no se hace por defecto. Para permitir que Erts hacen la scheduler-> núcleo afinidad uso:

erlang:system_flag(scheduler_bind_type, default_bind) -> PrevBind 

Varios otros tipos de vinculación se pueden encontrar en la documentación. ¡Usar afinidad puede mejorar enormemente el rendimiento en situaciones de carga pesada! Especialmente en situaciones de contención de bloqueo alto. Además, el kernel de Linux no puede manejar hyperthreads por decir lo menos. Si tienes hyperthreads en tu plataforma, deberías usar esta característica en erlang.

Answer 4

Me gustaría agregar algo de información a lo que se describió en la respuesta aceptada.

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

Cada programador se ejecuta dentro de una única cadena del sistema operativo. Normalmente, hay tantos programadores como CPU (núcleos) en el hardware (es configurable y, naturalmente, no aporta mucho valor cuando el número de programadores excede el de los núcleos de hardware). El sistema también puede estar configurado para que el programador no salte entre los hilos del sistema operativo.

Ahora, cuando se crea el proceso de Erlang es enteramente la responsabilidad de los equipos de expertos y el planificador para gestionar el ciclo de vida y el consumo de recursos, así como su capacidad de memoria, etc.

Uno de los detalles de implementación central 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. Cada progreso en el sistema (incluso E/S) tiene garantizado un presupuesto de reducciones. Eso es lo que hace de ERTS un sistema con multitarea preventiva.

Yo recomendaría una gran entrada en el blog sobre ese tema por Jesper Andersen Louis http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-scheduling.html

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