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 kernel de Linux (publicada en 1999) han demostrado que: [4]
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:
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:
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 highIOPriorityOtras 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:
jdk.internal.vm.Continuationclase especial.Los subprocesos verdes, los subprocesos proporcionados por la JVM, se ejecutan a nivel de usuario, lo que significa que la JVM crea y programa los subprocesos por sí misma. Por lo tanto, el núcleo del sistema operativo no los crea ni los programa. En cambio, el sistema operativo subyacente ve a la JVM solo como un subproceso. Los subprocesos verdes resultan ineficientes por varias razones. En primer lugar, los subprocesos verdes no pueden aprovechar un sistema multiprocesador (...) Por lo tanto, los subprocesos de la JVM están destinados a ejecutarse dentro de ese único subproceso de la JVM que se ejecuta dentro de un solo procesador.
{{cite web}}: CS1 maint: bot: original URL status unknown (link)En máquinas con múltiples CPU, los subprocesos nativos pueden ejecutar más de un subproceso simultáneamente asignando diferentes subprocesos a diferentes CPU. Los subprocesos verdes se ejecutan solo en una CPU.
Para sistemas con grandes volúmenes de correo electrónico, este enfoque ingenuo puede no funcionar bien. Los subprocesos nativos conllevan un mayor costo de inicialización y sobrecarga de memoria que los subprocesos verdes, por lo que JRuby normalmente no puede admitir más de aproximadamente 10 000 subprocesos. Para solucionar esto, podemos usar un grupo de subprocesos.
Como resultado, surgieron varios problemas: las aplicaciones Java no podían interoperar con las aplicaciones MT existentes en el entorno Solaris, los hilos Java no podían ejecutarse en paralelo en multiprocesadores, una aplicación Java MT no podía aprovechar la verdadera concurrencia del sistema operativo para aplicaciones más rápidas en monoprocesadores o multiprocesadores. Para aumentar sustancialmente el rendimiento de la aplicación, la biblioteca de hilos verdes se reemplazó con hilos nativos de Solaris para Java en la plataforma Solaris 2.6; esto se mantiene en las plataformas Solaris 7 y Solaris 8.
El beneficio de rendimiento que supone utilizar hilos nativos en una máquina MP puede ser espectacular. Por ejemplo, si se utiliza un punto de referencia artificial en el que los hilos de Java realizan el procesamiento de forma independiente entre sí, puede producirse una mejora de velocidad general de tres veces en una máquina MP de 4 CPU.
una sobrecarga de procesamiento significativa para que la JVM realice un seguimiento de los estados de los hilos y los intercambie, por lo que el modo de hilo verde ha quedado obsoleto y se ha eliminado de las implementaciones de Java más recientes.
Un
hilo
es una cadena de ejecución en el espacio de trabajo de APL.
Por ejemplo, tanto Go como Haskell necesitan algún tipo de "hilos verdes", por lo que hay más desafíos de ejecución compartidos de lo que podría esperarse.
Los lugares permiten el desarrollo de programas paralelos que aprovechan las máquinas con múltiples procesadores, núcleos o subprocesos de hardware. Un lugar es una tarea paralela que es, en efecto, una instancia independiente de la máquina virtual Racket.
Se incluye un programador de turnos rotativos. Se puede utilizar para programar tareas de forma cooperativa o preventiva.