Hilo (informática)

A nivel del núcleo, un proceso contiene uno o más hilos del núcleo , que comparten los recursos del proceso, como la memoria y los descriptores de archivo; un proceso es una unidad de recursos, mientras que un hilo es una unidad de planificación y ejecución. La planificación del núcleo se realiza normalmente de forma uniforme, de manera preventiva o, con menos frecuencia, de forma cooperativa. A nivel de usuario, un proceso como un sistema de tiempo de ejecución puede planificar por sí mismo múltiples hilos de ejecución. Si estos no comparten datos, como en Erlang , se les suele llamar procesos de forma análoga, ^{[ 9 ]} mientras que si comparten datos se les suele llamar hilos (de usuario) , especialmente si se planifican de forma preventiva. Los hilos de usuario planificados de forma cooperativa se conocen como fibras ; diferentes procesos pueden planificar los hilos de usuario de forma diferente. Los hilos de usuario pueden ser ejecutados por hilos del núcleo de diversas maneras (uno a uno, muchos a uno, muchos a muchos). El término proceso ligero se refiere indistintamente a los hilos de usuario o a los mecanismos del núcleo para planificar hilos de usuario en hilos del núcleo.

Un proceso es una unidad pesada de planificación del kernel, ya que crear, destruir y cambiar de proceso 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 archivo , sockets, identificadores de dispositivo, ventanas y un bloque de control de proceso . Los procesos están aislados por el aislamiento de procesos y no comparten espacios de direcciones ni recursos de archivo excepto a través de métodos explícitos como heredar identificadores de archivo o segmentos de memoria compartida, o mapear el mismo archivo de forma compartida (véase Comunicación entre procesos) . Crear o destruir un proceso es relativamente costoso, ya que se deben adquirir o liberar recursos. Los procesos suelen ser multitarea con prioridad, 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 la caché (en particular, el cambio de proceso cambia el direccionamiento de la memoria virtual, lo que provoca la invalidación y, por lo tanto, el vaciado de un búfer de traducción de direcciones (TLB) sin etiquetar, especialmente en x86 ).

Un hilo del kernel es una unidad ligera de planificación del kernel. Existe al menos un hilo del kernel en cada proceso. Si existen varios hilos del kernel en un proceso, comparten la misma memoria y los mismos recursos de archivos. Los hilos del kernel se ejecutan de forma preventiva si el planificador de procesos del sistema operativo es preventivo. Los hilos del kernel no poseen recursos, excepto una pila , una copia de los registros , incluido el contador de programa , y ​​almacenamiento local del hilo (si lo hay), por lo que su creación y destrucción son relativamente económicas. El cambio de hilo también es relativamente económico: requiere un cambio de contexto (guardando y restaurando registros y el puntero de pila), pero no modifica la memoria virtual y, por lo tanto, es compatible con la caché (manteniendo la TLB válida). El kernel puede asignar uno o más hilos de software a cada núcleo de una CPU (pudiendo asignarse a sí mismo varios hilos de software según su compatibilidad con la multihilo) y puede intercambiar los hilos que se bloquean. Sin embargo, el intercambio de hilos del kernel tarda mucho más que el de los hilos de usuario.

En ocasiones, los hilos se implementan en bibliotecas de espacio de usuario , por lo que se denominan hilos de usuario . El núcleo no tiene conocimiento de ellos, por lo que se gestionan y planifican en el espacio de usuario. Algunas implementaciones basan sus hilos de usuario en varios hilos del núcleo para aprovechar las ventajas de las máquinas multiprocesador ( modelo M:N ). Los hilos de usuario implementados mediante máquinas virtuales también se denominan hilos verdes .

Dado que las implementaciones de hilos de usuario suelen estar completamente en el espacio de usuario, el cambio de contexto entre hilos de usuario dentro del mismo proceso es extremadamente eficiente, ya que no requiere ninguna interacción con el núcleo: un cambio de contexto se puede realizar guardando localmente los registros de la CPU utilizados por el hilo de usuario o fibra que se está ejecutando y, a continuación, cargando los registros necesarios para la ejecución del hilo o fibra. Como la planificación se realiza en el espacio de usuario, la política de planificació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 (a diferencia de los subprocesos del kernel) puede ser problemático. Si un subproceso de usuario o una fibra realiza una llamada al sistema que bloquea, los demás subprocesos de usuario y fibras del proceso no pueden ejecutarse hasta que la llamada al sistema finalice. Un ejemplo típico de este problema se da al realizar operaciones de entrada/salida (E/S): la mayoría de los programas están diseñados para realizar E/S de forma síncrona. Cuando se inicia una operación de E/S, se realiza una llamada al sistema que no finaliza hasta que la operación se haya completado. Durante este tiempo, todo el proceso queda bloqueado por el kernel 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 (utilizada, en particular, por muchas implementaciones de hilos ligeros) consiste en proporcionar una API de E/S que implemente una interfaz que bloquee el hilo 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 hilo 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 puede escribirse para evitar el uso de E/S síncrona u otras llamadas al sistema bloqueantes (en particular, utilizando E/S no bloqueante, incluyendo continuaciones lambda y/o primitivas async/ await ^{[ 10 ]} ).

Las fibras son una unidad de planificación aún más ligera que se planifica de forma cooperativa : una fibra en ejecución debe ceder explícitamente el paso para permitir que otra fibra se ejecute, lo que hace que su implementación sea mucho más sencilla que la de los hilos del kernel o de usuario . Una fibra puede planificarse para ejecutarse en cualquier hilo del mismo proceso. Esto permite que las aplicaciones obtengan mejoras de rendimiento al gestionar la planificación por sí mismas, en lugar de depender del planificador del kernel (que puede no estar optimizado para la aplicación). Algunas implementaciones de investigación del modelo de programación paralela OpenMP implementan sus tareas a través de fibras. ^{[ 11 ] [ 12 ]} 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 hilos se diferencian de los procesos multitarea tradicionales del sistema operativo en varios aspectos:

• Los procesos suelen ser independientes, mientras que los hilos existen como subconjuntos de un proceso.
• Los procesos contienen mucha más información de estado que los hilos, mientras que varios hilos 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 hilos 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 suele ocurrir 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 caros ; en otros sistemas operativos no hay tanta diferencia, excepto en el coste de un cambio de espacio de direcciones , que en algunas arquitecturas (en particular x86 ) da como resultado un vaciado del búfer de traducción anticipada (TLB).

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

• Menor consumo de recursos de los hilos: al usar hilos, una aplicación puede funcionar con menos recursos de los que necesitaría si utilizara múltiples procesos.
• Simplificación del intercambio y la comunicación entre hilos: 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 hilos pueden comunicarse a través de datos, código y archivos que ya comparten.
• Un hilo puede provocar el bloqueo de un proceso : debido a que los hilos comparten el mismo espacio de direcciones, una operación ilegal realizada por un hilo puede provocar el bloqueo de todo el proceso; por lo tanto, un hilo que se comporta de forma anómala puede interrumpir el procesamiento de todos los demás hilos de la aplicación.

Los sistemas operativos programan los hilos de forma preventiva o cooperativa . Los sistemas operativos multiusuario generalmente prefieren la programación preventiva para un control más preciso del tiempo de ejecución mediante el cambio de contexto . Sin embargo, la programación preventiva puede provocar cambios de contexto en los hilos en momentos inesperados para los programadores, lo que puede causar bloqueos en cadena , inversión de prioridad u otros efectos secundarios. Por el contrario, la programación cooperativa se basa en que los hilos cedan el control de la ejecución, asegurando así que se completen . Esto puede causar problemas si un hilo con multitarea cooperativa se bloquea esperando un recurso o si impide que otros hilos accedan a él 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 una sola CPU de un solo núcleo, sin soporte para subprocesos de hardware , aunque estos se seguían utilizando en dichas computadoras porque el cambio entre subprocesos generalmente seguía siendo más rápido que los cambios de contexto de proceso completos . En 2002, Intel agregó soporte para multihilo simultáneo al procesador Pentium 4 , bajo el nombre de hyper-threading ; en 2005, presentaron el procesador de doble núcleo Pentium D y AMD presentó el procesador de doble núcleo Athlon 64 X2 .

Los sistemas con un solo procesador generalmente implementan la multihilo mediante la división del tiempo : la unidad central de procesamiento (CPU) cambia entre diferentes hilos de software . Este cambio de contexto suele ocurrir con la suficiente frecuencia como para que los usuarios perciban que los hilos o tareas se ejecutan en paralelo (en los sistemas operativos populares para servidores y ordenadores de escritorio, el tiempo máximo de ejecución de un hilo, mientras otros hilos esperan, suele estar limitado a 100-200 ms). En un sistema multiprocesador o multinúcleo , varios hilos pueden ejecutarse en paralelo , y cada procesador o núcleo ejecuta un hilo independiente simultáneamente; en un procesador o núcleo con hilos de hardware , los hilos de software independientes también pueden ejecutarse concurrentemente mediante hilos de hardware independientes.

Los hilos de un 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 forma conveniente, sin la sobrecarga ni la complejidad de una comunicación entre procesos (IPC) . Sin embargo, cuando se comparten entre hilos, 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 hilos pueden intentar actualizar la estructura de datos al mismo tiempo y encontrarse con 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) para subprocesos ofrecen primitivas de sincronización, como los mutex , para bloquear las estructuras de datos e impedir el acceso concurrente. En sistemas monoprocesador, un subproceso que encuentra un mutex bloqueado debe entrar en estado de espera y, por lo tanto, provocar un cambio de contexto. En sistemas multiprocesador, el subproceso puede, en cambio, consultar el mutex mediante un spinlock . Ambas opciones pueden mermar 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 utiliza hilos es el de grupos de hilos, donde se crea un número determinado de hilos al inicio que esperan a que se les asigne una tarea. Cuando llega una nueva tarea, el hilo se activa, la completa y vuelve a esperar. Esto evita las funciones de creación y destrucción de hilos, que son relativamente costosas para cada tarea, y libera al desarrollador de la gestión de hilos, dejándola en manos de una biblioteca o del sistema operativo, que está mejor capacitado para optimizarla.

Si todos los subprocesos están ocupados, se colocan elementos de trabajo adicionales en una cola hasta que un subproceso esté disponible para ejecutarlos. ^{[ 17 ]}

Las aplicaciones multihilo presentan las siguientes ventajas frente a las de un solo hilo:

• Capacidad de respuesta : el uso de subprocesos múltiples permite que una aplicación responda a las entradas del usuario. En un programa de un solo subproceso, si el subproceso principal se bloquea en una tarea de larga duración, la aplicación puede parecer congelada. Al trasladar estas tareas de larga duración a un subproceso de trabajo que se ejecuta simultáneamente con el subproceso principal, la aplicación puede seguir 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 subprocesos múltiples no es la única forma de mantener la capacidad de respuesta de un programa, ya que se pueden utilizar señales de E/S no bloqueantes o de Unix para obtener resultados similares. ^{[ 18 ]}
• Paralelización : las aplicaciones que buscan utilizar sistemas multinúcleo o multi-CPU pueden usar multihilo para dividir datos y tareas en subtareas paralelas y dejar que la arquitectura subyacente gestione cómo se ejecutan los hilos, ya sea concurrentemente en un núcleo o en paralelo en varios núcleos. Los entornos de computación GPU como CUDA , OpenCL y DirectX 12 utilizan el modelo de multihilo donde decenas o cientos de hilos se ejecutan en paralelo sobre los datos en un gran número de núcleos . Esto, a su vez, permite una mejor utilización del sistema y (siempre que los costos de sincronización no absorban los beneficios) puede proporcionar una ejecución de programas más rápida.

Las aplicaciones multihilo presentan los siguientes inconvenientes:

• Complejidad de sincronización y errores relacionados: al usar recursos compartidos típicos de programas multihilo, el programador debe tener cuidado para evitar condiciones de carrera y otros comportamientos poco intuitivos. Para que los datos se manipulen correctamente, los hilos a menudo necesitarán coincidir en el tiempo para procesar los datos en el orden correcto. Los hilos también pueden requeriroperaciones mutuamente excluyentes (a menudo implementadas usando mutexes ) para evitar que los datos comunes se lean o sobrescriban en un hilo mientras otro los modifica. El uso descuidado de tales primitivas puede llevar a interbloqueos , bloqueos permanentes o condiciones de carrera por los recursos. Además, el multihilo puede aumentar el uso de recursos del sistema , incluida la RAM . ^{[ 19 ]} Como escribió Edward A. Lee : «Aunque los hilos parecen ser un pequeño paso desde la computación secuencial, de hecho, representan un paso enorme. Descartan las propiedades más esenciales y atractivas de la computación secuencial: comprensibilidad, predictibilidad y determinismo. Los hilos, como modelo de computación, son tremendamente no deterministas, y la tarea del programador se convierte en la de podar ese no determinismo». ^{[ 20 ]}
• La imposibilidad de probarlos . En general, los programas multihilo no son deterministas y, por lo tanto, son imposibles de probar. En otras palabras, un programa multihilo puede tener fácilmente errores que nunca se manifiestan en un sistema de prueba, sino solo en producción. ^{[ 21 ] [ 20 ]} Esto se puede mitigar restringiendo las comunicaciones entre hilos a ciertos patrones bien definidos (como el paso de mensajes).
• Costos de sincronización . Dado que el cambio de contexto de subprocesos en las CPU modernas puede costar hasta 1 millón de ciclos de CPU, ^{[ 22 ]} resulta difícil escribir programas multihilo eficientes. En particular, se debe prestar especial atención para evitar que la sincronización entre subprocesos sea demasiado frecuente.