Hilo (informática)

En informática , un hilo de ejecución es la secuencia más pequeña de instrucciones programadas que puede gestionar de forma independiente un programador , que normalmente forma parte del sistema operativo . ^[1] En muchos casos, un hilo es un componente de un proceso .

Los múltiples subprocesos de un proceso determinado pueden ejecutarse simultáneamente (mediante capacidades de subprocesamiento múltiple), compartiendo recursos como la memoria , mientras que los diferentes procesos no comparten estos recursos. En particular, los subprocesos de un proceso comparten su código ejecutable y los valores de sus variables asignadas dinámicamente y las variables globales no locales del subproceso en un momento dado.

La implementación de subprocesos y procesos difiere entre sistemas operativos. ^{[2] [ página necesaria ]}

Esta sección necesita ser ampliada . Puedes ayudar agregándole algo. ( Febrero 2021 )

Los subprocesos aparecieron por primera vez bajo el nombre de "tareas" en el sistema operativo de procesamiento por lotes de IBM, OS/360, en 1967. Proporcionaban a los usuarios tres configuraciones disponibles del sistema de control OS/360, de las cuales la multiprogramación con un número variable de tareas (MVT) era una. Saltzer (1966) atribuye a Victor A. Vyssotsky el término "subproceso". ^[3]

El uso de subprocesos en aplicaciones de software se volvió más común a principios de la década de 2000, cuando las CPU comenzaron a utilizar múltiples núcleos. Las aplicaciones que deseaban aprovechar los múltiples núcleos para obtener ventajas de rendimiento debían emplear la concurrencia para utilizar los múltiples núcleos. ^[4]

La programación se puede realizar a nivel de núcleo o de usuario, y la multitarea se puede realizar de forma preventiva o cooperativa . Esto genera una variedad de conceptos relacionados.

A nivel de núcleo, un proceso contiene uno o más hilos de núcleo , que comparten los recursos del proceso, como la memoria y los controladores de archivos: un proceso es una unidad de recursos, mientras que un hilo es una unidad de programación y ejecución. La programación del núcleo generalmente se realiza de manera uniforme de manera preventiva o, con menos frecuencia, de manera cooperativa. A nivel de usuario, un proceso como un sistema en tiempo de ejecución puede programar múltiples hilos de ejecución. Si estos no comparten datos, como en Erlang, generalmente se denominan procesos de manera análoga, ^[5] mientras que si comparten datos, generalmente se denominan hilos (de usuario) , particularmente si se programan de manera preventiva. Los hilos de usuario programados de manera cooperativa se conocen como fibras ; diferentes procesos pueden programar hilos de usuario de manera diferente. Los hilos de usuario pueden ser ejecutados por hilos de núcleo de varias maneras (uno a uno, muchos a uno, muchos a muchos). El término " proceso liviano " se refiere de diversas maneras a los hilos de usuario o a los mecanismos del núcleo para programar hilos de usuario en hilos de núcleo.

Un proceso es una unidad "pesada" de la programación del núcleo, ya que crear, destruir y cambiar procesos es relativamente costoso. Los procesos poseen recursos asignados por el sistema operativo. Los recursos incluyen memoria (tanto para código como para datos), identificadores de archivos , sockets, identificadores de dispositivos, ventanas y un bloque de control de procesos . Los procesos están aislados por aislamiento de procesos y no comparten espacios de direcciones o recursos de archivos excepto a través de métodos explícitos como heredar identificadores de archivos o segmentos de memoria compartida, o mapear el mismo archivo de manera compartida - ver comunicación entre procesos . Crear o destruir un proceso es relativamente costoso, ya que los recursos deben adquirirse o liberarse. Los procesos suelen ser multitarea preventivas, y el cambio de proceso es relativamente costoso, más allá del costo básico del cambio de contexto , debido a problemas como el vaciado de caché (en particular, el cambio de proceso cambia el direccionamiento de memoria virtual, causando invalidación y, por lo tanto, vaciado de un búfer de traducción no etiquetado (TLB), especialmente en x86).

Un hilo de kernel es una unidad "liviana" de programación de kernel. Existe al menos un hilo de kernel dentro de cada proceso. Si existen múltiples hilos de kernel dentro de un proceso, entonces comparten los mismos recursos de memoria y archivo. Los hilos de kernel son multitarea preventiva si el programador de procesos del sistema operativo es preventivo. Los hilos de kernel no poseen recursos excepto una pila , una copia de los registros que incluyen el contador de programa y el almacenamiento local de hilo (si lo hay), y por lo tanto son relativamente baratos de crear y destruir. El cambio de hilo también es relativamente barato: requiere un cambio de contexto (guardar y restaurar registros y puntero de pila), pero no cambia la memoria virtual y, por lo tanto, es compatible con la caché (dejando válida la TLB). El kernel puede asignar uno o más hilos de software a cada núcleo en una CPU (pudiendo asignarse a sí mismo múltiples hilos de software dependiendo de su soporte para multihilo), y puede intercambiar hilos que se bloquean. Sin embargo, los hilos de kernel tardan mucho más en intercambiarse que los hilos de usuario.

Los subprocesos a veces se implementan en bibliotecas de espacio de usuario , por lo que se denominan subprocesos de usuario . El núcleo no los conoce, por lo que se administran y programan en el espacio de usuario. Algunas implementaciones basan sus subprocesos de usuario en varios subprocesos del núcleo, para aprovechar las máquinas multiprocesador (modelo M:N). Los subprocesos de usuario implementados por máquinas virtuales también se denominan subprocesos verdes .

Como las implementaciones de subprocesos de usuario suelen realizarse completamente en el espacio de usuario, el cambio de contexto entre subprocesos de usuario dentro del mismo proceso es extremadamente eficiente porque no requiere ninguna interacción con el núcleo: se puede realizar un cambio de contexto guardando localmente los registros de CPU utilizados por el subproceso de usuario o la fibra que se está ejecutando actualmente y luego cargando los registros que requiere el subproceso de usuario o la fibra que se va a ejecutar. Dado que la programación se realiza en el espacio de usuario, la política de programación se puede adaptar más fácilmente a los requisitos de la carga de trabajo del programa.

Sin embargo, el uso de llamadas al sistema bloqueantes en subprocesos de usuario (en contraposición a subprocesos del núcleo) puede ser problemático. Si un subproceso de usuario o una fibra realiza una llamada al sistema que se bloquea, los demás subprocesos de usuario y fibras del proceso no pueden ejecutarse hasta que la llamada al sistema regrese. Un ejemplo típico de este problema es cuando se realiza una operación de E/S: la mayoría de los programas están escritos para realizar E/S de forma sincrónica. Cuando se inicia una operación de E/S, se realiza una llamada al sistema y no regresa hasta que se ha completado la operación de E/S. En el período intermedio, todo el proceso está "bloqueado" por el núcleo y no puede ejecutarse, lo que impide que otros subprocesos de usuario y fibras del mismo proceso se ejecuten.

Una solución común a este problema (usada, en particular, por muchas implementaciones de subprocesos verdes) es proporcionar una API de E/S que implemente una interfaz que bloquee el subproceso que realiza la llamada, en lugar de todo el proceso, mediante el uso interno de E/S no bloqueante y la programación de otro subproceso de usuario o fibra mientras la operación de E/S está en curso. Se pueden proporcionar soluciones similares para otras llamadas al sistema bloqueantes. Alternativamente, el programa se puede escribir para evitar el uso de E/S sincrónicas u otras llamadas al sistema bloqueantes (en particular, utilizando E/S no bloqueantes, incluidas las continuaciones lambda y/o primitivas async/ await ^[6] ).

Las fibras son una unidad de programación aún más ligera que se programa de forma cooperativa : una fibra en ejecución debe " ceder " explícitamente para permitir que se ejecute otra fibra, lo que hace que su implementación sea mucho más sencilla que los subprocesos del núcleo o del usuario. Una fibra se puede programar para que se ejecute en cualquier subproceso del mismo proceso. Esto permite que las aplicaciones obtengan mejoras de rendimiento al gestionar la programación por sí mismas, en lugar de depender del programador del núcleo (que puede no estar ajustado para la aplicación). Algunas implementaciones de investigación del modelo de programación paralela OpenMP implementan sus tareas a través de fibras. ^{[7] [8]} Estrechamente relacionadas con las fibras están las corrutinas , con la distinción de que las corrutinas son una construcción a nivel de lenguaje, mientras que las fibras son una construcción a nivel de sistema.

Los subprocesos se diferencian de los procesos multitarea tradicionales del sistema operativo en varios aspectos:

• Los procesos suelen ser independientes, mientras que los subprocesos existen como subconjuntos de un proceso.
• Los procesos llevan considerablemente más información de estado que los subprocesos, mientras que varios subprocesos dentro de un proceso comparten el estado del proceso, así como la memoria y otros recursos.
• Los procesos tienen espacios de direcciones separados , mientras que los subprocesos comparten su espacio de direcciones.
• Los procesos interactúan únicamente a través de mecanismos de comunicación entre procesos proporcionados por el sistema.
• El cambio de contexto entre subprocesos en el mismo proceso generalmente ocurre más rápido que el cambio de contexto entre procesos.

Se dice que sistemas como Windows NT y OS/2 tienen subprocesos baratos y procesos costosos ; en otros sistemas operativos no hay una diferencia tan grande excepto en el costo de un cambio de espacio de direcciones , que en algunas arquitecturas (especialmente x86 ) resulta en un vaciado del buffer de búsqueda de traducción (TLB).

Las ventajas y desventajas de los subprocesos frente a los procesos incluyen:

• Menor consumo de recursos de los subprocesos: al utilizar subprocesos, una aplicación puede funcionar utilizando menos recursos de los que necesitaría al utilizar varios procesos.
• Uso compartido y comunicación simplificados de subprocesos: a diferencia de los procesos, que requieren un mecanismo de paso de mensajes o de memoria compartida para realizar la comunicación entre procesos (IPC), los subprocesos pueden comunicarse a través de datos, código y archivos que ya comparten.
• Un hilo hace que un proceso se bloquee : debido a que los hilos comparten el mismo espacio de direcciones, una operación ilegal realizada por un hilo puede bloquear todo el proceso; por lo tanto, un hilo que se comporta mal puede interrumpir el procesamiento de todos los demás hilos de la aplicación.

Los sistemas operativos programan los subprocesos de forma preventiva o cooperativa . Los sistemas operativos multiusuario generalmente favorecen el multiproceso preventivo por su control más preciso sobre el tiempo de ejecución a través del cambio de contexto . Sin embargo, la programación preventiva puede cambiar de contexto los subprocesos en momentos no previstos por los programadores, lo que provoca convoyes de bloqueo , inversión de prioridad u otros efectos secundarios. Por el contrario, el multiproceso cooperativo se basa en que los subprocesos renuncien al control de la ejecución, lo que garantiza que los subprocesos se ejecuten hasta el final . Esto puede causar problemas si un subproceso multitarea cooperativo se bloquea al esperar un recurso o si deja sin recursos a otros subprocesos al no ceder el control de la ejecución durante un cálculo intensivo.

Hasta principios de la década de 2000, la mayoría de las computadoras de escritorio tenían solo una CPU de un solo núcleo, sin soporte para subprocesos de hardware , aunque los subprocesos aún se usaban en dichas computadoras porque el cambio entre subprocesos generalmente seguía siendo más rápido que los cambios de contexto de proceso completo . En 2002, Intel agregó soporte para subprocesamiento múltiple simultáneo al procesador Pentium 4 , bajo el nombre de hiperprocesamiento ; en 2005, presentaron el procesador Pentium D de doble núcleo y AMD presentó el procesador Athlon 64 X2 de doble núcleo .

Los sistemas con un solo procesador generalmente implementan el multihilo mediante la división en segmentos de tiempo : la unidad central de procesamiento (CPU) cambia entre diferentes subprocesos de software . Este cambio de contexto suele ocurrir con la suficiente frecuencia como para que los usuarios perciban que los subprocesos o las tareas se ejecutan en paralelo (en los sistemas operativos populares de servidores y escritorios, la máxima división de tiempo de un subproceso, cuando otros subprocesos están esperando, suele estar limitada a 100-200 ms). En un sistema multiprocesador o multinúcleo , varios subprocesos pueden ejecutarse en paralelo , y cada procesador o núcleo ejecuta un subproceso independiente simultáneamente; en un procesador o núcleo con subprocesos de hardware , los subprocesos de software independientes también pueden ejecutarse simultáneamente por subprocesos de hardware independientes.

Los subprocesos creados por el usuario en una correspondencia 1:1 con entidades programables en el núcleo ^[9] son ​​la implementación de subprocesos más simple posible. OS/2 y Win32 usaron este enfoque desde el principio, mientras que en Linux la biblioteca C de GNU implementa este enfoque (a través de NPTL o LinuxThreads más antiguos ). Este enfoque también lo usan Solaris , NetBSD , FreeBSD , macOS e iOS .

Un modelo M :1 implica que todos los hilos de nivel de aplicación se asignan a una entidad programada a nivel de núcleo; ^[9] el núcleo no tiene conocimiento de los hilos de aplicación. Con este enfoque, el cambio de contexto se puede realizar muy rápidamente y, además, se puede implementar incluso en núcleos simples que no admiten subprocesos. Sin embargo, una de las principales desventajas es que no puede beneficiarse de la aceleración de hardware en procesadores multiproceso o computadoras multiprocesador : nunca se programa más de un hilo al mismo tiempo. ^[9] Por ejemplo: si uno de los hilos necesita ejecutar una solicitud de E/S, todo el proceso se bloquea y no se puede utilizar la ventaja de los subprocesos. GNU Portable Threads utiliza subprocesos a nivel de usuario, al igual que State Threads .

M : N asigna una cantidad M de subprocesos de aplicación a una cantidad N de entidades del núcleo ^[9] o "procesadores virtuales". Se trata de un compromiso entre la creación de subprocesos a nivel del núcleo ("1:1") y a nivel del usuario (" N :1"). En general, los sistemas de subprocesos " M : N " son más complejos de implementar que los subprocesos del núcleo o del usuario, porque se requieren cambios tanto en el código del núcleo como en el del espacio del usuario ^{[ se necesita una aclaración ]} . En la implementación M:N, la biblioteca de subprocesos es responsable de programar los subprocesos del usuario en las entidades programables disponibles; esto hace que el cambio de contexto de los subprocesos sea muy rápido, ya que evita las llamadas del sistema. Sin embargo, esto aumenta la complejidad y la probabilidad de inversión de prioridad , así como de una programación subóptima sin una coordinación extensa (y costosa) entre el programador del espacio del usuario y el programador del núcleo.

• Activaciones del programador utilizadas por versiones anteriores de la implementación de la biblioteca de subprocesos POSIX nativos de NetBSD (un modelo M : N en lugar de un modelo de implementación de kernel o espacio de usuario 1:1)
• Procesos livianos utilizados por versiones anteriores del sistema operativo Solaris
• Marcel del proyecto PM2 .
• El sistema operativo para el Tera- Cray MTA-2
• El compilador Glasgow Haskell (GHC) para el lenguaje Haskell utiliza subprocesos livianos que se programan en subprocesos del sistema operativo.

SunOS 4.x implementó procesos livianos o LWPs. NetBSD 2.x+ y DragonFly BSD implementan LWPs como hilos del núcleo (modelo 1:1). SunOS 5.2 a SunOS 5.8 así como NetBSD 2 a NetBSD 4 implementaron un modelo de dos niveles, multiplexando uno o más hilos de nivel de usuario en cada hilo del núcleo (modelo M:N). SunOS 5.9 y posteriores, así como NetBSD 5 eliminaron el soporte de hilos de usuario, volviendo a un modelo 1:1. ^[10] FreeBSD 5 implementó el modelo M:N. FreeBSD 6 admitía tanto 1:1 como M:N, los usuarios podían elegir cuál debería usarse con un programa determinado utilizando /etc/libmap.conf. A partir de FreeBSD 7, el 1:1 se convirtió en el predeterminado. FreeBSD 8 ya no admite el modelo M:N.

En programación informática , el procesamiento monohilo es el procesamiento de un comando a la vez. ^{[11] En el análisis formal de} la semántica de las variables y el estado del proceso, el término monohilo se puede utilizar de forma diferente para significar "retroceder dentro de un solo hilo", lo cual es común en la comunidad de programación funcional . ^[12]

El multihilo se encuentra principalmente en sistemas operativos multitarea. El multihilo es un modelo de programación y ejecución muy extendido que permite que existan varios subprocesos dentro del contexto de un proceso. Estos subprocesos comparten los recursos del proceso, pero pueden ejecutarse de forma independiente. El modelo de programación por subprocesos proporciona a los desarrolladores una abstracción útil de la ejecución concurrente. El multihilo también se puede aplicar a un proceso para permitir la ejecución en paralelo en un sistema multiprocesamiento .

Las bibliotecas de subprocesos múltiples suelen proporcionar una llamada a una función para crear un nuevo subproceso, que toma una función como parámetro. A continuación, se crea un subproceso simultáneo que comienza a ejecutar la función pasada y finaliza cuando la función retorna. Las bibliotecas de subprocesos también ofrecen funciones de sincronización de datos.

Los subprocesos del mismo proceso comparten el mismo espacio de direcciones. Esto permite que el código que se ejecuta simultáneamente se acople estrechamente e intercambie datos de manera conveniente sin la sobrecarga o la complejidad de un IPC . Sin embargo, cuando se comparten entre subprocesos, incluso las estructuras de datos simples se vuelven propensas a condiciones de carrera si requieren más de una instrucción de CPU para actualizarse: dos subprocesos pueden terminar intentando actualizar la estructura de datos al mismo tiempo y descubrir que cambia inesperadamente. Los errores causados ​​por condiciones de carrera pueden ser muy difíciles de reproducir y aislar.

Para evitar esto, las interfaces de programación de aplicaciones (API) de subprocesos ofrecen primitivas de sincronización , como mutexes, para bloquear las estructuras de datos contra el acceso simultáneo. En sistemas monoprocesador, un subproceso que se ejecuta en un mutex bloqueado debe dormir y, por lo tanto, activar un cambio de contexto. En sistemas multiprocesador, el subproceso puede, en cambio, sondear el mutex en un spinlock . Ambos pueden minar el rendimiento y obligar a los procesadores en sistemas de multiprocesamiento simétrico (SMP) a competir por el bus de memoria, especialmente si la granularidad del bloqueo es demasiado fina.

Otras API de sincronización incluyen variables de condición , secciones críticas , semáforos y monitores .

Un patrón de programación popular que involucra subprocesos es el de los grupos de subprocesos , donde se crea una cantidad determinada de subprocesos al inicio que luego esperan a que se les asigne una tarea. Cuando llega una nueva tarea, se activa, completa la tarea y vuelve a esperar. Esto evita las funciones relativamente costosas de creación y destrucción de subprocesos para cada tarea realizada y quita la gestión de subprocesos de las manos del desarrollador de la aplicación y la deja en manos de una biblioteca o del sistema operativo que sea más adecuado para optimizar la gestión de subprocesos.

Las aplicaciones multiproceso tienen las siguientes ventajas frente a las de un solo subproceso:

• Capacidad de respuesta : el uso de múltiples subprocesos permite que una aplicación siga respondiendo a las entradas. En un programa de un solo subproceso, si el subproceso de ejecución principal se bloquea en una tarea de larga duración, puede parecer que toda la aplicación se congela. Al mover esas tareas de larga duración a un subproceso de trabajo que se ejecuta simultáneamente con el subproceso de ejecución principal, es posible que la aplicación siga respondiendo a las entradas del usuario mientras ejecuta tareas en segundo plano. Por otro lado, en la mayoría de los casos, el uso de múltiples subprocesos no es la única forma de mantener un programa responsivo, ya que hay disponibles señales de E/S y/o Unix sin bloqueo para obtener resultados similares. ^[13]
• Paralelización : las aplicaciones que buscan utilizar sistemas multinúcleo o multi-CPU pueden utilizar multithreading para dividir datos y tareas en subtareas paralelas y dejar que la arquitectura subyacente administre cómo se ejecutan los subprocesos, ya sea de manera concurrente en un núcleo o en paralelo en múltiples núcleos. Los entornos de computación GPU como CUDA y OpenCL utilizan el modelo multithreading donde docenas a cientos de subprocesos se ejecutan en paralelo a través de datos en una gran cantidad de núcleos . Esto, a su vez, permite una mejor utilización del sistema y (siempre que los costos de sincronización no consuman los beneficios), puede proporcionar una ejecución más rápida del programa.

Las aplicaciones multiproceso tienen las siguientes desventajas:

• Complejidad de sincronización y errores relacionados: al utilizar recursos compartidos típicos de los programas con subprocesos, el programador debe tener cuidado de evitar condiciones de carrera y otros comportamientos no intuitivos. Para que los datos se manipulen correctamente, los subprocesos a menudo necesitarán encontrarse a tiempo para procesar los datos en el orden correcto. Los subprocesos también pueden requerir operaciones mutuamente excluyentes (a menudo implementadas mediante mutexes ) para evitar que se lean o sobrescriban datos comunes en un subproceso mientras otro los modifica. El uso descuidado de tales primitivos puede conducir a bloqueos , bloqueos activos o carreras por los recursos. Como ha escrito Edward A. Lee : "Aunque los subprocesos parecen ser un pequeño paso desde el cálculo secuencial, de hecho, representan un gran paso. Descartan las propiedades más esenciales y atractivas del cálculo secuencial: comprensibilidad, previsibilidad y determinismo. Los subprocesos, como modelo de cálculo, son tremendamente no deterministas, y el trabajo del programador se convierte en el de podar ese no determinismo". ^[14]
• No es posible realizar pruebas . En general, los programas multiproceso no son deterministas y, como resultado, no se pueden realizar pruebas. En otras palabras, un programa multiproceso puede tener fácilmente errores que nunca se manifiestan en un sistema de prueba, sino que solo se manifiestan en producción. ^{[15] [14]} Esto se puede aliviar restringiendo las comunicaciones entre subprocesos a ciertos patrones bien definidos (como el paso de mensajes).
• Costos de sincronización . Como el cambio de contexto de subprocesos en las CPU modernas puede costar hasta un millón de ciclos de CPU, ^[16] esto dificulta la escritura de programas multiproceso eficientes. En particular, se debe prestar especial atención para evitar que la sincronización entre subprocesos sea demasiado frecuente.

Muchos lenguajes de programación admiten subprocesos de alguna manera.

• IBM PL/I (F) incluía compatibilidad con subprocesos múltiples (denominados multitarea ) a finales de los años 60, y esto se mantuvo en el compilador Optimizing y versiones posteriores. El compilador IBM Enterprise PL/I introdujo una nueva API de "subprocesos" de modelo. Ninguna de las dos versiones formaba parte del estándar PL/I.
• Muchas implementaciones de C y C++ admiten subprocesos y brindan acceso a las API de subprocesos nativas del sistema operativo. Una interfaz estandarizada para la implementación de subprocesos es POSIX Threads (Pthreads), que es un conjunto de llamadas a la biblioteca de funciones de C. Los proveedores de sistemas operativos tienen la libertad de implementar la interfaz como deseen, pero el desarrollador de aplicaciones debe poder usar la misma interfaz en múltiples plataformas. La mayoría de las plataformas Unix , incluido Linux, admiten Pthreads. Microsoft Windows tiene su propio conjunto de funciones de subprocesos en la interfaz process.h para subprocesos múltiples, como beginthread .
• Algunos lenguajes de programación de nivel superior (y generalmente multiplataforma ), como Java , Python y los lenguajes .NET Framework , exponen el subprocesamiento a los desarrolladores mientras abstraen las diferencias específicas de la plataforma en las implementaciones de subprocesamiento en el tiempo de ejecución. Varios otros lenguajes de programación y extensiones de lenguaje también intentan abstraer el concepto de concurrencia y subprocesamiento del desarrollador por completo ( Cilk , OpenMP , Message Passing Interface (MPI)). Algunos lenguajes están diseñados para el paralelismo secuencial en cambio (especialmente utilizando GPU), sin requerir concurrencia o subprocesos ( Ateji PX , CUDA ).
• Algunos lenguajes de programación interpretados tienen implementaciones (por ejemplo, Ruby MRI para Ruby, CPython para Python) que admiten subprocesos y concurrencia, pero no ejecución paralela de subprocesos, debido a un bloqueo de intérprete global (GIL). El GIL es un bloqueo de exclusión mutua mantenido por el intérprete que puede evitar que el intérprete interprete simultáneamente el código de la aplicación en dos o más subprocesos a la vez. Esto limita efectivamente el paralelismo en sistemas de múltiples núcleos. También limita el rendimiento de los subprocesos limitados al procesador (que requieren el procesador), pero no afecta tanto a los limitados a E/S o a la red. Otras implementaciones de lenguajes de programación interpretados, como Tcl que utiliza la extensión Thread, evitan el límite de GIL mediante el uso de un modelo de apartamentos donde los datos y el código deben "compartirse" explícitamente entre subprocesos. En Tcl, cada subproceso tiene uno o más intérpretes.
• En modelos de programación como CUDA diseñados para computación paralela de datos , una matriz de subprocesos ejecuta el mismo código en paralelo utilizando solo su ID para encontrar sus datos en la memoria. En esencia, la aplicación debe estar diseñada de manera que cada subproceso realice la misma operación en diferentes segmentos de memoria para que puedan operar en paralelo y utilizar la arquitectura de la GPU.
• Los lenguajes de descripción de hardware como Verilog tienen un modelo de subprocesos diferente que admite una cantidad extremadamente grande de subprocesos (para modelar hardware).

Wikiversidad tiene recursos de aprendizaje sobre procesos y subprocesos en

Sistemas operativos/Procesos e hilos