Sistemas Operativos

Una aplicación multihilo interactiva puede continuar ejecutando tareas aunque uno o varios hilos de la misma estén bloqueados o realizando operaciones muy lentamente, mejorando así el tiempo de respuesta al usuario.

Por ejemplo, un navegador web multihilo puede gestionar la interacción del usuario a través de un hilo, mientras el contenido solicitado se descarga en otro. Para hacer lo mismo en un navegador monohilo habría que utilizar comunicaciones asíncronas, de lo contrario, mientras el proceso está en estado esperando, a la espera de que lleguen los datos a través de la red, no puede atender las acciones del usuario.

En sistemas operativos monohilo se pueden crear varios procesos y comunicarlos mediante memoria compartida para conseguir algo similar a lo que ofrecen los sistemas multihilo. Sin embargo, al utilizar hilos, las tareas ejecutadas en ellos comparten los recursos automáticamente, sin que tengamos que hacer nada. Además, los hilos no solo comparten la memoria, sino también otros muchos recursos del proceso. Por lo que los hilos son una forma más conveniente de tener procesos que realizan diferentes actividades al mismo tiempo.

Reservar memoria y otros recursos para la creación de un proceso es muy costoso. Por eso los sistemas operativos modernos han desarrollado diversas técnicas para que sea lo más eficaz posible.

Aun así, puesto que los hilos comparten los recursos de los procesos a los que pertenecen, son mucho más económicos de crear. También es más económico el cambio de contexto entre ellos, ya que hay que guardar y recuperar menos información al cambiar entre dos hilos de un mismo proceso.

Por ejemplo, en Microsoft Windows crear un proceso puede ser 300 veces más costoso que un hilo. Mientras que en sistemas Linux es 3 veces más lento, por la eficiencia de fork().

En los sistemas multiprocesador diferentes hilos pueden ejecutarse en paralelo en distintos procesadores. Por el contrario, un proceso monohilo solo se puede ejecutar en una CPU a la vez, independientemente de cuantas CPU estén disponibles para ejecutarlo.

El soporte de hilos a nivel de usuario se implementan mediante un librería de hilos en el espacio de usuario, junto al código del programa y los datos del proceso, sin requerir ningún soporte especial por parte del núcleo del sistema operativo. Por tanto, como se puede observar en el lado derecho de la Figura 12.3, estos hilos existen desde el punto de vista del proceso y del programa que ejecuta, pero no para el sistema operativo. El planificador de la CPU asigna tiempo de CPU a los procesos, mientras que la librería de hilos de cada proceso reparte el tiempo de ejecución del proceso entre los diferentes hilos de este.

Como el código y los datos de la librería residen en el espacio de usuario, invocar una función de la misma se reduce a una simple llamada a una función, evitando el coste de hacer llamadas al sistema.

Se habla de hilos a nivel de núcleo, cuando el núcleo del sistema es el encargado de ofrecer el soporte multihilo. El código y los datos de la librería de hilos, mediante la cual los programadores pueden solicitar la creación y gestión de los hilos, reside en el espacio del núcleo. Por tanto, para invocar una función de la librería de hilos es necesario hacer una llamada al sistema. Obviamente, la librería del sistema ofrece las funciones necesarias para realizar estas llamadas al sistema de forma sencilla.

La implementación del soporte de hilos en el núcleo implica cambios respecto a lo que hemos visto hasta el momento de la gestión de procesos, puesto que, en estos sistemas, es el hilo la unidad básica de uso de la CPU, como se ilustra en la Figura 12.3. Es decir, son los hilos los que se mueven por los estados del Figura 9.2 y las colas de la Figura 9.3, en lugar de los procesos. En estos sistemas, el planificador de la CPU selecciona un hilo para ejecutarse en la CPU de entre todos los que están en el estado preparado en el sistema y el cambio de contexto asigna la CPU a un hilo distinto al que la tiene asignada en el momento actual, que puede ser del mismo o de diferente proceso.

Aparte del PCB que vimos en el Apartado 9.3, ahora el sistema operativo también gestiona una estructura llamada bloque de control del hilo o TCB (Thread Control Block) para cada hilo en el sistema, donde se guarda información sobre su estado de actividad actual. Por tanto, es en TCB —y no en el PCB— donde se guarda la información privada del hilo necesaria para la gestión de los estados y para el cambio de contexto, como: los valores de los registros de la CPU y el contador de programa, el estado o la información de planificación de la CPU; además de un puntero al PCB al que pertenece el hilo con el resto de la información privada del proceso.

En la actualidad, en los diferentes sistemas operativos se pueden encontrar librerías de ambos tipos.

Por ejemplo, la librería de hilos de Windows API se implementa en el núcleo[19] mientras que la librería de hilos POSIX Threads —frecuentemente utilizada en los sistemas POSIX— puede ser de ambos tipos, dependiendo solamente del sistema donde se implemente. En Linux y en la mayor parte de los UNIX modernos, POSIX Threads se implementa en el núcleo del sistema.

En el modelo muchos a uno muchos hilos de usuario son mapeados en un único hilo de núcleo. El planificador de la CPU en el núcleo reparte el tiempo de CPU entre los diferentes hilos de núcleo en el sistema, mientras que la librería de hilos en cada proceso reparte el tiempo de ejecución del hilo de núcleo del proceso entre múltiples hilos de usuario (véase la Figura 12.4).

Los sistemas modernos son multihilo, por lo que al crearse un proceso siempre se crea con un hilo de núcleo inicial, que es al que el núcleo asigna tiempo de CPU. Sin embargo, los sistemas más antiguos no tienen ningún soporte de hilos en el núcleo, por lo que no hay hilos de núcleo. En este sentido, quizás sería más correcto definir el modelo muchos a uno como aquel en el que muchos hilos de usuario son mapeados en una «única entidad planificable en la CPU». En los sistemas más antiguos estas entidades son los procesos, de forma que, bajo este modelo multihilo los hilos de usuario realmente se reparten el tiempo de ejecución del proceso al que pertenecen.

El modelo muchos a uno corresponde al caso en el que solo se implementan hilos a nivel de usuario, que es el caso ilustrado a la izquierda en la Figura 12.3.

En el modelo muchos a uno un hilo de usuario se mapea en un único hilo de núcleo.

Por lo general, este modelo corresponde al caso de los sistemas que solo soportan hilos a nivel de núcleo. En este caso, la librería de hilos se implementa en el núcleo, por lo que las entidades que planifica el núcleo en la CPU son los hilos de núcleo y los procesos pueden gestionar estos hilos mediante llamadas al sistema (véase la Figura 12.7).

Es importante tener en cuenta que, a efectos prácticos, los hilos de usuario de la Figura 12.7 no son hilos diferentes a los hilos de núcleo. Realmente, son los mismos hilos de núcleo, pero vistos desde la perspectiva del programa en el modo usuario, como se ilustra a la derecha en la Figura 12.3.

En teoría debería ser posible aprovechar lo mejor de los dos modelos anteriores con una librería de hilos en el núcleo, para crear hilos de núcleo, y otra en el espacio de usuario, para crear hilos de usuario. Así los desarrolladores pueden utilizar la librería de hilos en el espacio de usuario para crear tantos hilos como quieran y que estos se ejecuten sobre los hilos de núcleo de su proceso.

El planificador de la librería de hilos en espacio de usuario se encarga de determinar como se reparte el tiempo de ejecución de cada hilo de núcleo entre los hilos de usuario. Mientras que el planificador de la CPU asigna la CPU a alguno de los hilos de núcleo del sistema (véase la Figura 12.8).

Existe una variación del modelo muchos a muchos donde, además de funcionar de la forma comentada anteriormente, se permite que un hilo de usuario quede ligado indefinidamente a un único hilo de núcleo, como en el modelo uno a uno.

Esta variación se denomina, en ocasiones, modelo de dos niveles (véase la Figura 12.10).

Hemos comentado que el modelo muchos a uno debe ser, teóricamente, «más ligero» que el modelo uno a uno. También hemos dicho que el modelo muchos a muchos, teóricamente, permite conservar esa ventaja, al tiempo que ofrece los beneficios del modelo uno a uno, en lo que respecta al aprovechamiento de los sistemas multiprocesador. Sin embargo, debemos tener en cuenta que la diferencia real puede variar en función de múltiples factores.

Un criterio común hasta la década de los 2000, era que el modelo uno a uno era adecuado hasta varias decenas hilos —a lo sumo, en torno a 100 o, quizás, a unos pocos cientos de hilos— por proceso, mientras que el modelo muchos a uno podía llegar a varios miles de hilos.

La principal limitación en la cantidad de hilos de usuario del modelo muchos a uno estaba en el tamaño del espacio de direcciones del proceso. Por ejemplo, en las versiones de Windows de 32 bits, los procesos dispone de 2 GiB de su espacio de direcciones para código y datos. Como cada fibra —que es como se llama a los hilos del modelo multihilo muchos a uno que implementa la API Win32 de Windows— necesita 1 MiB de memoria para su pila, el límite teórico era de 2048 fibras. Este límite era realmente algo inferior porque en el mismo espacio se almacena el código y los datos del programa y las librerías que este utiliza.

Una forma de soslayar este problema es indicar al sistema que reserve menos memoria para la pila al crear cada fibra. Esta posibilidad la suelen soportar los sistemas operativos, independientemente del modelo multihilo. En el caso de Microsoft Windows, esto permite llegar hasta cerca de las 32 KiB fibras en sistemas de 32 bits.

Posteriormente, se optimizó la creación de hilos a nivel de núcleo, hasta el punto de equiparar, en gran medida, el coste de cada hilo en ambos modelos. Mientras que el pasar a sistemas de 64 bits, permitió superar las limitaciones derivadas por el pequeño tamaño del espacio de direcciones de los procesos en los sistemas de 32 bits, que limitaba a ambos modelos multihilo

Actualmente, la creación de hilos a nivel de núcleo se ha optimizado hasta el punto de que usando el modelo uno a uno se puede llegar a decenas o cientos de miles de hilos por proceso, equiparándose a muchas implementaciones del modelo muchos a uno.

Con suficiente memoria y ajustando el tamaño de la pila de los hilos, se puede llegar a millones de hilos en ambos modelos. Sin embargo, cuando se tienen requisitos tan específicos, suele recomendarse utilizar librerías o lenguajes específicos, con implementaciones concretas del modelo muchos a uno o muchos a muchos —siendo actualmente más interesante porque permite aprovechar el paralelismo de las CPU modernas— específicamente diseñadas para escalar hasta dicha cantidad de hilos.

Algunas de estas implementaciones son:

En un sistema operativo con librería de hilos implementada en el núcleo, todo proceso se crea con un hilo, denominado hilo principal. Este es con el que comienza a ejecutarse el programa al entrar en main() y el que provoca la terminación de todo el proceso —incluida la terminación de los otros hilos que existan— al retornar de dicha función.

El hilo principal puede crear otros hilos y estos, a su vez, crear los hilos que necesiten. Pero, a diferencia de lo que ocurre con los procesos, no existe una relación de padres a hijos ni se crea un árbol de hilos. Excepto por la característica especial del hilo principal de que su finalización significa la terminación del proceso, todos los hilos son iguales entre sí.

En el Ejemplo 12.1 se puede ver cómo se usa std::thread de la librería estándar de C++ para crear hilos.

En los sistemas POSIX, std::thread se implementa usando la librería del sistema POSIX Threads, mientras que en los sistemas Microsoft Windows utiliza la API Win32. En el Ejemplo 12.2 se puede ver código equivalente al del Ejemplo 12.1 pero usando directamente la API de POSIX Threads.

La cancelación es la operación de terminar un hilo antes de que termine su trabajo. Por ejemplo, en un navegador web un hilo se puede encargar de la interfaz de usuario mientras otros hilos se encargan de descargar las páginas y las imágenes de la misma. Si el usuario pulsa el botón Cancelar es necesario que todos los hilos que intervienen en la descarga sean cancelados.

Esto puede ocurrir de dos maneras:

En POSIX Threads un hilo puede solicitar la cancelación de otro hilo usando pthread_cancel().

El hilo identificado por el manejador thread será cancelado si está configurado como cancelable. Por defecto todos los hilos son cancelables, pero eso lo puede cambiar el propio hilo llamando a pthread_setcancelstate():

El tipo de cancelación se puede configurar con pthread_setcanceltype():

Se pueden cambiar entre estado y tipo de cancelación en cualquier momento, según lo que encaje mejor con las características de las distintas partes del código.

El mecanismo de cancelación de hilos descrito funciona razonablemente bien en C, pero no con lenguajes de más alto nivel, como C++, Java o C#. Las librerías de hilos suelen ser librerías en C, que no conocen nada de objetos ni de otras particularidades de esos lenguajes.

Por ejemplo, en C++, antes de terminar un hilo, deberían ser llamados todos los destructores de los objetos locales, para evitar fugas de memoria y de otros recursos, datos sin escribir y otros problemas derivados de tener objetos que no se destruyen adecuadamente. Lamentablemente, el mecanismo de cancelación de POSIX Threads —y el de otras librerías de hilos, como la de Windows API— no sabe hacer nada de eso. Cada lenguaje debe implementar su propia solución.

En Java y C#, por ejemplo, cuando un punto de cancelación detecta una petición de cancelación emite la excepción Thread.Interrupt, que retrocede por la pila de llamadas, liberando las variables locales hasta salir por el método principal del hilo. A este mecanismo se lo denomina cancelación coordinada.

En C++ no se ha incluido un mecanismo de cancelación en el estándar hasta C++20. Antes de C++20, la forma recomendada de implementar la cancelación es pasando a los hilos una variable de tipo bool con la que señalarles cuándo deben terminar. El código de los hilos debe comprobar frecuentemente el valor de dicha variable y, llegado el momento, terminar retornando ordenadamente por la función principal del hilo.

En C++20 esta estrategia de cancelación cooperativa se ha formalizado e incluido en el estándar al introducir la clase std::jthread. Esta nueva clase de hilo puede pasar a la función principal lo que se llama un token de cancelación —en lugar de una variable tipo bool— que se debe comprobar regularmente para saber si hay que terminar el hilo prematuramente.

Por ejemplo, la función del factorial podría hacer uso de esa funcionalidad para terminar cuando se lo indiquen:

Java y C# han terminado incluyendo también este tipo de cancelación cooperativa usando un token de cancelación, debido a los problemas que tienen los desarrolladores para recordar usar correctamente la excepción de la cancelación coordinada.

La llamada al sistema fork() de los sistemas POSIX es anterior a la existencia del concepto de hilo. Así que cuando estos aparecieron surgió el problema de si al llamar a fork() en un proceso multihilo:

Como hemos comentado anteriormente, la llamada al sistema fork() sustituye el programa en ejecución con un nuevo programa e inicia su ejecución en main(). Esto incluye liberar toda la memoria reservada y la destrucción de todos los hilos del programa original, por lo que duplicar los hilos en el proceso hijo creado por fork(), si luego se va a llamar a exec() parece algo innecesario.

El estándar POSIX establece que si se utiliza fork() en un programa multihilo, el nuevo proceso debe ser creado con un solo hilo, que será una réplica del que hizo la llamada, así como un duplicado completo del espacio de direcciones del proceso.

Sin embargo, algunos sistemas UNIX tienen una segunda llamada no estándar denominada forkall(), capaz de duplicar todos los hilos del proceso padre. Obviamente solo resulta conveniente emplearla si no se va a utilizar la llamada exec() a continuación. La inclusión de forkall() en el estándar POSIX fue considerada y rechazada.

En el Apartado 10.5.2 hablamos del uso de las señales como mecanismo de comunicación, pero en general sirven para informar a un proceso del suceso de ciertos eventos.

Existen dos tipos de señales:

Como hemos visto, las señales que llegan a un proceso pueden ser interceptadas por una función definida por el programador llamada manejador de señal.

Las señales también son anteriores a los hilos, por lo que cuando aparecieron los hilos se tuvieron que tomar decisiones sobre cómo iban a encajar ambos conceptos. Por ejemplo, decidir cuál de los hilos del proceso, será interrumpido cuando llegue una señal, para ejecutar el manejador de señales.