2010-04-02 11 views
13

He estado leyendo mucho sobre cómo Scala y Erlang tienen hilos ligeros y su modelo de concurrencia (actores).¿Scala y Erlang usan hilos verdes?

Sin embargo, tengo mis dudas.

¿Scala y Erlang usan un enfoque similar al antiguo modelo de subprocesos utilizado por Java (hilos verdes)?

Por ejemplo, supongamos que hay una máquina con 2 núcleos, por lo que el medio ambiente Scala/Erlang se bifurcará un hilo por procesador? Los otros subprocesos serán programados por el entorno de espacio de usuario (VM Scala/VM Erlang). ¿Es esto correcto?

Debajo del capó, ¿cómo funciona esto realmente?

+0

Java no ha usado hilos verdes en absoluto desde hace una década – vemv

Respuesta

23

Erlang está utilizando la multitarea espacio de usuario, ejecutar tareas hasta que se bloquean o hasta que hayan agotado su cuota de 'reducciones'. Una reducción se define vagamente como una unidad de cálculo.

Hasta el programador SMP, solo había un hilo del núcleo que tomaba tareas ejecutables. Con la programación de SMP tiene varios hilos del kernel que realizan tareas y, por lo tanto, ejecutan el código en paralelo en máquinas multi-core. La cantidad de subprocesos del planificador debe coincidir con la cantidad de núcleos. Consulte el interruptor -smp [enable|auto|disable] en the erl manpage.

También ha habido un grupo de subprocesos del kernel para los conductores que se pueden cargar para ejecutar sistema de bloqueo de llamadas. Esto se llama el grupo de subprocesos asincrónica. Ver +A size en the erl manpage.

Otras lecturas

+0

@gracias a Christian.Por lo tanto, el planificador multitarea de espacio de usuario elegirá algún "objeto de hilo" para ser ejecutado por el hilo del sistema operativo. derecho ? – CHAPa

+0

No puedo describirlo mucho mejor que el pdf de EUC'08 al que me he vinculado. Creo que el lanzamiento actual de OTP ahora tiene múltiples colas de ejecución como se describe en la sección 5.2, vivimos en el futuro. – Christian

+0

No, un hilo del sistema operativo ejecuta un programador de erlang que maneja explícitamente los procesos y su programación. Es por eso que rara vez tiene más de un hilo por núcleo, al menos para ejecutar el código de erlang, no es necesario. Los subprocesos del sistema operativo suelen ser demasiado pesados ​​para ser utilizados en los procesos de Erlang. – rvirding

1

Scala utiliza la implementación subyacente de subprocesos de Java, que uses native threads.

No se puede decir acerca de Erlang.

+0

Hola, Lo sé, la JVM más nueva usa solo hilos nativos, pero hay un problema para scala ser escalable usando solo hilos nativos. Entonces, algunos artículos que he leído decían que se usaba un conjunto de hilos (trabajadores) en el "entorno de simultaneidad" de Scala, y que la ideía es usar los hilos java menos posibles (hilos nativos). – CHAPa

+0

Anterior Akka (biblioteca de actor basada en Scala) estaba usando HawtDispatch (http://hawtdispatch.fusesource.org/). Pero han cambiado a algo más mientras tanto. No sé de qué se trata Si tiene interés, puede solicitarlos en el foro de Akka (akka.io) – OlliP

4

Para reciente información acerca de los detalles de implementación de Erlang comprobar fresh talk (slides).

+0

guay, buena conversación. Muchas gracias – CHAPa

13

Scala 2.8 utiliza grupos de subprocesos de Java. Los actores ligeros (Reactor) y los actores más pesados ​​en modo ligero (react {...}) no toman su propio hilo; más bien, cuando tienen un mensaje, toman un hilo hasta que terminan de procesar el mensaje, luego devuelven el hilo y no se ejecutan hasta que llega el siguiente mensaje.

This article da una descripción decente de Actores en 2.7; 2.8 no es tan diferente.

+0

@Rex, pero, para ser escalable, scala no puede usar solo el hilo Java (Thread OS nativo), debe ser capaz de crear un entorno donde esté disponible un nuevo tipo de hilo, como un hilo verde. Imagine, 100 actores, y cada actor usando un hilo de Java, este no es un hilo ligero, porque el contexto del hilo de cambio no es demasiado claro. derecho ? – CHAPa

+0

Eso es un poco correcto. Los interruptores no son tan livianos como Erlang. Casi siempre puede evitar tener 100 actores en 100 hilos (haciendo que reaccionen a los mensajes en lugar de ejecutarse constantemente), por lo que todavía tiene los subprocesos Java no livianos que sustentan todo el asunto, pero el consumo de mensajes más livianos (ya que los mensajes para múltiples los actores pueden ser procesados ​​por un hilo). Debido a esta arquitectura, puede escalar a muchos actores de estilo de reacción sin quedarse sin hilos de sistema operativo, pero no es tan increíblemente escalable como Erlang. (Buscar "tiroteo en el punto de referencia del anillo de rosca" ...) –

+0

@CHAPa Los actores de Akka se basan en las devoluciones de llamada, por lo que no se necesitan varios hilos. Este modelo es muy inferior desde una perspectiva de desarrollo, pero permite usarlo en una plataforma que solo ofrece agrupamiento de subprocesos. – rightfold