Hilo verde

En programación informática , un subproceso verde es un subproceso que está programado por una biblioteca de tiempo de ejecución o una máquina virtual (VM) en lugar de hacerlo de forma nativa por el sistema operativo (OS) subyacente. Los subprocesos verdes emulan entornos multiproceso sin depender de ninguna capacidad nativa del SO y se administran en el espacio del usuario en lugar del espacio del núcleo , lo que les permite funcionar en entornos que no tienen soporte nativo para subprocesos. ^[1]

Green threads hace referencia al nombre de la biblioteca de subprocesos original del lenguaje de programación Java (que se lanzó en la versión 1.1 y luego se abandonó en la versión 1.3 para convertirla en subprocesos nativos). Fue diseñada por The Green Team en Sun Microsystems . ^[2]

Los hilos verdes estuvieron disponibles brevemente en Java entre 1997 y 2000.

Los subprocesos verdes comparten un único subproceso del sistema operativo a través de la concurrencia cooperativa y, por lo tanto, no pueden lograr mejoras en el rendimiento del paralelismo como los subprocesos del sistema operativo. El principal beneficio de las corrutinas y los subprocesos verdes es la facilidad de implementación.

En un procesador multinúcleo , las implementaciones de subprocesos nativos pueden asignar trabajo automáticamente a varios procesadores, mientras que las implementaciones de subprocesos verdes normalmente no pueden hacerlo. ^{[1] [3]} Los subprocesos verdes se pueden iniciar mucho más rápido en algunas máquinas virtuales. Sin embargo, en computadoras con un solo procesador, aún no se ha determinado claramente el modelo más eficiente.

Los análisis comparativos realizados en ordenadores que ejecutan la versión 2.2 del núcleo Linux (publicada en 1999) han demostrado que: ^[4]

• Los subprocesos verdes superan significativamente a los subprocesos nativos de Linux en la activación y sincronización de subprocesos .
• Los subprocesos nativos de Linux tienen un rendimiento ligeramente mejor en operaciones de entrada/salida (E/S) y de cambio de contexto .

Cuando un hilo verde ejecuta una llamada al sistema que genera bloqueo, no solo se bloquea ese hilo, sino que también se bloquean todos los hilos dentro del proceso. ^[5] Para evitar ese problema, los hilos verdes deben utilizar operaciones de E/S no bloqueantes o de E/S asincrónicas , aunque la mayor complejidad del lado del usuario se puede reducir si la máquina virtual que implementa los hilos verdes genera procesos de E/S específicos (ocultos para el usuario) para cada operación de E/S. ^{[ cita requerida ]}

También existen mecanismos que permiten el uso de subprocesos nativos y reducen la sobrecarga de activación y sincronización de subprocesos:

• Los grupos de subprocesos reducen el costo de generar un nuevo subproceso al reutilizar una cantidad limitada de subprocesos. ^[6]
• Los lenguajes que utilizan máquinas virtuales y subprocesos nativos pueden utilizar el análisis de escape para evitar sincronizar bloques de código cuando no es necesario. ^[7]

En Java 1.1 , los subprocesos verdes eran el único modelo de subprocesos utilizado por la máquina virtual Java (JVM), ^[8] al menos en Solaris . Como los subprocesos verdes tienen algunas limitaciones en comparación con los subprocesos nativos, las versiones posteriores de Java los abandonaron en favor de los subprocesos nativos. ^{[9] [10]}

Una excepción a esto es la máquina virtual Squawk , que es una mezcla entre un sistema operativo para dispositivos de bajo consumo y una máquina virtual Java. Utiliza hilos verdes para minimizar el uso de código nativo y para soportar la migración de sus aislamientos.

Kilim ^{[11] [12]} y Quasar ^{[13] [14]} son ​​proyectos de código abierto que implementan subprocesos verdes en versiones posteriores de la JVM modificando el código de bytes de Java producido por el compilador de Java (Quasar también admite Kotlin y Clojure ).

Existen otros lenguajes de programación que implementan equivalentes de subprocesos verdes en lugar de subprocesos nativos. Ejemplos:

• Chicken Scheme utiliza subprocesos livianos a nivel de usuario basados ​​en continuaciones de primera clase ^[15]
• Ceceo común ^[16]
• CPython soporta de forma nativa asyncio desde la versión 3.4, existen implementaciones alternativas como greenlet, eventlet y gevent, PyPy ^[17]
• Crystal ofrece fibras ^[18]
• D ofrece fibras , utilizadas para E/S asíncronas ^[19]
• Los nombres APL de Dyalog son subprocesos ^[20]
• Erlang ^[21]
• Go implementa las llamadas gorutinas ^[22]
• Haskell ^[22]
• Julia utiliza hilos verdes para sus tareas.
• Limbo ^[23]
• Lua utiliza corrutinas para la concurrencia. Lua 5.2 también ofrece semántica de corrutina C real a través de las funciones lua_yieldk, lua_callk y lua_pcallk. La extensión CoCo permite una semántica de corrutina C real para Lua 5.1.
• Nim proporciona E/S asincrónicas y corrutinas
• OCaml , desde la versión 5.0, admite subprocesos verdes a través del módulo Domainslib.Task
• Occam , que prefiere el término proceso en lugar de hilo debido a sus orígenes en la comunicación de procesos secuenciales.
• Perl admite subprocesos verdes a través de corrutinas
• PHP admite subprocesos verdes a través de fibras y corrutinas
• Ruby antes de la versión 1.9 ^[24]
• Racket (los hilos nativos también están disponibles a través de Places ^[25] )
• Rust admite subprocesos del sistema de forma nativa ^[26] y admite E/S asincrónica a través de bibliotecas de terceros como Tokio
• Implementación de ML concurrente en SML/NJ
• Smalltalk (la mayoría de los dialectos: Squeak , VisualWorks, GNU Smalltalk , etc.)
• Python sin pila admite multitarea preventiva o multitarea cooperativa a través de microhilos (denominados tasklets ). ^[27]
• Tcl tiene corrutinas y un bucle de eventos ^[28]

La máquina virtual Erlang tiene lo que se podría llamar procesos verdes : son como procesos del sistema operativo (no comparten el estado como lo hacen los subprocesos), pero se implementan dentro del sistema de tiempo de ejecución Erlang (erts). A veces se los denomina subprocesos verdes , pero tienen diferencias significativas ^{[ aclaración necesaria ]} con respecto a los subprocesos verdes estándar. ^{[ cita requerida ]}

En el caso de GHC Haskell, se produce un cambio de contexto en la primera asignación después de un tiempo de espera configurable. Los subprocesos GHC también se ejecutan potencialmente en uno o más subprocesos del sistema operativo durante su vida útil (existe una relación de muchos a muchos entre los subprocesos GHC y los subprocesos del sistema operativo), lo que permite el paralelismo en máquinas multiprocesadoras simétricas , sin crear subprocesos del sistema operativo más costosos de los necesarios para ejecutarse en la cantidad de núcleos disponibles. ^{[ cita requerida ]}

La mayoría de las máquinas virtuales de Smalltalk no cuentan los pasos de evaluación; sin embargo, la máquina virtual puede adelantarse al subproceso en ejecución en caso de señales externas (como temporizadores que expiran o E/S que se vuelven disponibles). Por lo general, se utiliza la programación por turnos para que un proceso de alta prioridad que se activa regularmente implemente de manera efectiva la adelantamiento de tiempo compartido :

[
    [( Retraso de  milisegundos:  50 ) esperar ] repetir 
 ] forkAt:  Procesador  highIOPriority

Otras implementaciones, por ejemplo, QKS Smalltalk, siempre comparten el tiempo. A diferencia de la mayoría de las implementaciones de subprocesos verdes, QKS también permite evitar la inversión de prioridad .

Los hilos virtuales se introdujeron como una característica de vista previa en Java 19 ^[29] y se estabilizaron en Java 21. ^[30] Las diferencias importantes entre los hilos virtuales y los hilos verdes son:

• Los subprocesos virtuales coexisten con subprocesos y grupos de subprocesos de plataforma (no virtuales) existentes.
• Los hilos virtuales protegen su abstracción:
  • A diferencia de lo que ocurre con los hilos verdes, dormir en un hilo virtual no bloquea el hilo portador subyacente.
  • Se deja de lado el trabajo con variables locales del hilo y se sugieren valores con alcance como un reemplazo más liviano. ^[31]
• Los hilos virtuales se pueden suspender y reanudar de forma económica, haciendo uso del soporte de JVM para la jdk.internal.vm.Continuationclase especial.
• Los subprocesos virtuales manejan las llamadas de bloqueo desmontándose de forma transparente del subproceso portador cuando es posible; de ​​lo contrario, lo compensan aumentando la cantidad de subprocesos de la plataforma.

• Asíncrono/espera
• Proceso ligero
• Corrutina
• Máquina virtual Java
• Bloqueo de intérprete global
• Fibra (informática)
• Hilos portátiles de GNU
• Protohilos

• "Cuatro para la posteridad", artículo de JavaWorld sobre los hilos verdes
• Hilos verdes en las preguntas frecuentes sobre hilos de Java