Programación Concurrente Introducción al concepto de hilos

Transcripción

1 1 Programación Concurrente Introducción al concepto de hilos Por José Mª Toribio Vicente Universidad de Valladolid edited by jsm Barcelona, España. 7/11/2000 Comunicaciones entre procesos Las aplicaciones informáticas pueden ser de muchos tipos, desde procesadores de texto hasta procesadores de transacciones (bases de datos), simuladores de cálculo intensivo, etc. Las aplicaciones están formadas de uno o más programas. Los programas constan de código para la computadora donde se ejecutarán. El código es generalmente ejecutado de forma secuencial. Normalmente, un "programa hilado" (threaded program, programa construido mediante hilos) tiene el potencial de incrementar el rendimiento total de la aplicación en cuanto a productividad y tiempo de respuesta mediante ejecución de código asíncrono y paralelo. La ejecución de código paralelo se realiza mediante la ejecución de dos o más partes de un programa en dos o más procesadores en un instante dado. La ejecución asíncrona se puede realizar conmutando la ejecución del segmento de código actual que se bloquea por alguna razón, a otro segmento. Los hilos permiten al programador emplear estas características y muchas otras. Otros beneficios de los hilos están relacionados con los recursos compartidos y el escaso tiempo empleado en su creación, terminación y cambio de contexto. Todo esto contribuye a incrementar el rendimiento de la aplicación así como conservar los recursos del sistema. Cuando un programa se activa en el sistema, es decir está en ejecución o es candidato para la ejecución, se le conoce como un proceso. Cuando un proceso se encuentra activo, se le asignan una serie de recursos del sistema operativo para gestionarle, entre ellos una entrada en la tabla de procesos, un área de usuario, un contexto de registros único, memoria virtual, etc. La mayoría de los sistemas operativos sólo soportan procesos. Los procesos pueden ser vistos como una entidad "hilo simple", es decir, ejecutan sólo un flujo de instrucciones de una forma secuencial. Los procesos son planificados para ejecución una y otra vez hasta que finalizan, es decir, el programa termina su tarea. Cuando es planificado, un proceso se ejecutará en un procesador durante un intervalo de tiempo llamado quantum de tiempo. Un quantum es simplemente la cantidad de tiempo que el proceso tiene permitido para su ejecución antes de que el sistema operativo compruebe si existe un proceso de mayor prioridad listo para la ejecución. Un nuevo proceso es planificado para ejecución en lugar del proceso actual cuando: 1. El quantum de tiempo del proceso actual finaliza. 2. El proceso actual se bloquea, duerme, finaliza, o es desalojado. Siendo un hilo simple, una aplicación puede ejecutarse sólo en un procesador en un instante dado y sólo puede ejecutarse de forma secuencial. Una forma de incrementar la velocidad de ejecución de un programa secuencial sería dividir el trabajo entre múltiples procesadores. Es aquí donde los hilos resultan útiles. En los sistemas operativos tradicionales, cada proceso tiene un espacio de direcciones y un único hilo de control (contador de programa). Es lo que normalmente se entiende por proceso. Sin embargo, existen ocasiones en las que sería conveniente que dos procesos trabajasen de forma concurrente pero con una serie de datos comunes. Este problema es difícil de resolver normalmente, ya que los procesos son independientes y la comunicación de los datos debe realizarse mediante algún mecanismo de comunicación entre procesos (IPC), como pueden ser: semáforos, memoria compartida, paso de mensajes, etc. Pero parece claro que se introduce una cierta complejidad en la resolución de este tipo de problemas. Una solución que parece razonable consistiría en que los "procesos" compartiesen el espacio de direcciones (la memoria), de esta forma no sería necesario su intercomunicación, ya que todos tendrían acceso a la misma zona de memoria. Se plantean sin embargo otros problemas, como es el acceso concurrente a una misma posición de memoria, evitando los problemas de inconsistencia de datos. El significado exacto del término thread no está acordado. Uno de los usos más habituales denota a procesos ligeros (con flujo de control secuencial) que comparten un espacio de direcciones y algunos otros recursos, y para los cuales el tiempo empleado en el cambio de contexto es mucho menor que el empleado en los procesos pesados (procesos soportados por el kernel del sistema operativo). Los hilos son flujos de control independientes dentro de un mismo proceso que comparten datos globales (variables globales, ficheros, etc.), pero poseen una pila, variables locales y contador de programa, propios. Se les suele llamar "procesos de peso ligero" porque su contexto es menor que el contexto de un proceso. Por lo tanto, los cambios de contexto entre hilos son menos costosos que los cambios de contexto entre procesos. Además, los hilos son un modelo adecuado para explotar el paralelismo en un entorno multiprocesador de memoria compartida. La gestión de procesos es uno de los aspectos claves en el diseño de un sistema operativo. De la optimización de su funcionamiento depende en gran medida la buena utilización del sistema y sus recursos.

2 2 La historia de los hilos La noción de hilo, como flujo de control secuencial, se remonta al menos, al año 1965 [OSU96], con el sistema de tiempo compartido de Berkeley. Sólo que en aquel tiempo no fueron llamados hilos, sino procesos. Los procesos interactuaban a través de variables compartidas, semáforos, o mecanismos similares. Max Smith realizó un prototipo de implementación de hilos en Multics alrededor de 1970; usaba pilas múltiples en un proceso pesado simple para soportar compilaciones en background. Sin embargo, el progenitor más importante de los hilos fue el lenguaje de programación PL/I, hacia el año El lenguaje, según fue definido por IBM, proporcionaba una instrucción del tipo CALL XXX (A, B) TASK; construcción que bifurcaba generando un hilo para XXX. No se sabe si algún compilador de IBM implementó esta característica, pero fue estudiado exhaustivamente mientras se estaba diseñando Multics; se comprobó que la llamada TASK como estaba definida no mapeaba en procesos, ya que no existía protección entre los hilos de control. Entonces Multics tomó una dirección diferente, y la característica TASK fue eliminada de PL/I por IBM. Después vino UNIX, a principios de La noción UNIX de 'proceso' consistía en un hilo de control secuencial más un espacio de direcciones virtuales (esta noción derivó directamente del proceso de diseño de Multics). Así pues 'procesos', en el sentido de UNIX, son "máquinas pesadas". Ya que no pueden compartir memoria (cada proceso tiene su propio espacio de direcciones), interactuan a través de tuberías, señales, etc. La memoria compartida fue añadida a UNIX mucho más tarde. Después de algún tiempo, los usuarios de UNIX comenzaron a echar en falta los viejos procesos que podían compartir memoria. Esto dio lugar a la "invención" de los hilos: procesos al "viejo estilo" que compartían el espacio de direcciones de un simple proceso UNIX. Se les llamó, entonces, procesos ligeros en contraste con los procesos pesados UNIX. Esta distinción se remonta a finales de los 70's y principios de los 80's, cuando comenzaron los desarrollos de los primeros microkernels: Thoth (precursor del V-Kernel y QNX), Amoeba, Chorus, la familia RIG-Accent-Mach, etc. En relación con los paquetes de hilos, C Threads fue una de las implementaciones iniciales de hilos, nacida como una extensión del lenguaje C basada en corrutinas. Una implementación sencilla fue empleada por Cooper [COO88] como herramienta de enseñanza. Esta implementación original no gestionaba señales por hilo, y sólo soportaba planificación no preemptiva. El primer sistema operativo comercial que implementó hilos fue Mach. Cooper construyó una implementación de C Threads basada en los hilos Mach que soportaba planificación preemptiva. También existe una implementación anterior, realizada en Brown University [DOE87], de una biblioteca de hilos con planificación preemptiva, soporte de diversas arquitecturas (incluso multiprocesadores) y gestión de señales asíncronas. Posteriormente, algunos sistemas operativos comerciales, como LynxOS o SunOS, implementaron alguno de los diversos borradores del estándar POSIX Threads, empleando un método mixto a dos niveles, basado en una biblioteca de nivel usuario y soporte kernel de hilos. Otros sistemas operativos, como Chorus implementaron la mayor parte de la funcionalidad en el kernel, debido a sus requisitos de diseño. Características de las implementaciones Se pueden distinguir dos tipos de implementaciones de los hilos: hilos a nivel de usuario y los hilos a nivel de kernel. Un hilo a nivel de usuario mantiene todo su estado en el espacio de usuario. Como consecuencia de ello, el hilo no utiliza recursos del kernel para su gestión, y se puede conmutar entre hilos sin cambiar el espacio de direcciones. Como desventaja, los hilos a nivel de usuario no se pueden ejecutar mientras el kernel está ocupado, por ejemplo, con paginación o E/S, ya que esto necesitaría algún conocimiento y participación por parte del kernel. Es posible combinar ambos métodos, como se hace en SunOS 5.x (Solaris 2.x). Aquí, uno o más procesos ligeros (light weight processes - LWPs) se ejecutan en multitarea mediante uno o más hilos de nivel usuario, que son implementados usando librerías en el espacio de usuario. Algunas razones que caracterizan las implementaciones de hilos, y que determinan el uso que puede tener un paquete de hilos, son: El número de recursos del kernel que necesitará un hilo. Esto limitará el número de hilos que pueden iniciarse para una proceso. En qué momento el proceso entero será suspendido. Por ejemplo, si algún hilo genera una falta de página, entonces otro hilo del proceso puede ser ejecutado o no. La conmutación entre hilos requiere una llamada al sistema (como en la SPARC), o bien el cambio de contexto entre hilos se puede realizar completamente a nivel de usuario. El número de señales gestionadas, si las señales pueden ser enmascaradas individualmente por cada hilo o no, y si existe una señal de tipo broadcast. El número de pilas gestionadas, y si las pilas crecerán y decrecerán dinámicamente en base a cada hilo. Algunos nuevos sistemas (QNX y Plan 9, por ejemplo) consideran que los hilos "resuelven el síntoma, pero no el problema". En estos sistemas se considera que en vez de usar hilos, ya que el tiempo de cambio de contexto del SO es demasiado lento, una mejor aproximación, es mejorar el SO en sí. Parece irónico, que ahora que los SO para ordenadores de sobremesa incluyen multitarea en modo protegido, el modelo de programación de moda consiste en múltiples hilos ejecutándose en un espacio de direcciones común, haciendo el proceso de depuración más difícil, e incluso haciendo más difícil la generación de código fiable.

3 3 Con la ventaja de tener un rápido cambio de contexto, y existiendo servicios del SO, como la reserva explícita de memoria compartida entre un equipo de procesos cooperando, se puede crear un entorno de hilos, sin tener los problemas que se establecerían en un espacio de memoria totalmente compartida. Concepto de hilo A continuación se intentará explicar el concepto de hilo mediante un ejemplo. Imaginemos un servidor de archivos que ocasionalmente debe bloquearse esperando acceder al disco. Si el servidor tuviera varios hilos de control, se podría ejecutar un segundo hilo de control mientras el primero está suspendido. Esto provocaría un mejor rendimiento y utilización de los recursos. Si se crean dos procesos servidores independientes, ambos deberían compartir el buffer de caché, para lo cual deberían tener un espacio de direcciones común, lo cual complica su diseño. Normalmente se necesita un nuevo mecanismo que generalmente no se encuentra en los sistemas operativos, aunque no existe razón para esto. Figura 3-1 Tres procesos cada uno con un hilo. Supongamos tres procesos independientes, cada uno con su propio contador de programa, su propia pila, su propio conjunto de registros y su propio espacio de direcciones. Los procesos no tienen ninguna relación entre sí, excepto que pueden comunicarse mediante primitivas del sistema para comunicación entre procesos: semáforos, paso de mensaje, monitores, etc. pila independiente). Como cada hilo tiene acceso a cualquier dirección virtual, un hilo puede leer, escribir o limpiar la pila de otro hilo de su mismo proceso. No existe protección entre los hilos, ya que es muy difícil proporcionarla y no debe ser necesaria. Normalmente los procesos, que pueden ser de distintos usuarios, pueden ser hostiles entre sí. En cambio en un sistema multihilo, un proceso pertenece a un único usuario, y puede haber creado varios hilos para que cooperen entre sí. Los hilos, además de compartir el espacio de direcciones, comparten el conjunto de ficheros abiertos, procesos hijos, relojes, señales, etc. Así pues, los hilos resultan útiles cuando se necesite cooperación activa y cercana en la resolución de un mismo problema. Elementos de un Hilo Elementos de un Proceso Contador de programa espacio de direcciones Pila variables globales Registros descriptores de archivos hilos hijos procesos hijos Estado señales semáforos relojes información contable Todos los hilos comparten el mismo espacio de direcciones, y así comparten también las mismas variables globales. Mientras que los procesos pueden ser de distintos usuarios y competir por recursos entre si, los hilos de un mismo proceso de usuario cooperan entre si, sin luchar entre sí. Al igual que los procesos tradicionales, los hilos pueden estar en alguno de los siguientes estados: En ejecución (Running): cuando el hilo posee la CPU y se encuentra activo. Figura 3-2 Un proceso con tres hilos. Supongamos otra máquina, con un sólo proceso, pero dicho proceso tiene varios hilos de control, que suelen llamarse procesos ligeros o simplemente hilos (threads). Los hilos son como miniprocesos, ya que cada hilo se ejecuta de forma estrictamente secuencial, tiene su propio contador de programa y su propia pila. Los hilos comparten la CPU al igual que lo hacen los procesos en un sistema de tiempo compartido. Sólo en un sistema multiprocesador se pueden ejecutar realmente en paralelo. Los hilos pueden crear, igualmente, hilos hijos, y se pueden bloquear esperando la finalización de una llamada al sistema. Mientras un hilo se encuentra bloqueado, se puede ejecutar otro hilo del mismo proceso, exactamente igual que ocurre cuando un proceso se bloquea y se ejecuta otro proceso en la misma máquina. La analogía "hilo es a proceso, como proceso es a máquina" es válida en muchos sentidos. Sin embargo los hilos de un mismo proceso no son tan independientes como los procesos distintos. Todos los hilos de un proceso comparten el mismo espacio de direcciones, con lo cual comparten las mismas variables globales (las variables locales no son compartidas, ya que se almacenan en la pila, y cada hilo tiene su propia Bloqueado (Suspend): cuando el hilo se encuentra esperando algún evento o a la espera de que otro libere el bloqueo por el que se encuentra detenido. Listo o preparado (Ready): cuando el hilo está preparado para su ejecución, y se encuentra a la espera de ser elegido por el planificador. Terminado (Finished): cuando el hilo ha finalizado, pero todavía no ha sido recogido por el hilo padre, aunque no puede ser planificado nunca más. Además, en algunas ocasiones (según el diseño) un hilo puede ser independizado (no tiene relación de parentesco con ningún otro) en conjunción con cualquiera de los estados anteriores. Cuando un hilo independizado finaliza o cuando un hilo finalizado es independizado, cualquier memoria asociada con él es liberada y el hilo no puede volver a ser referenciado. Un proceso puede tener uno o más hilos. Los hilos son un mecanismo que permite mejorar el rendimiento de los sistemas operativos tratando de reducir la sobrecarga producida por el cambio de contexto entre procesos. Los hilos de un mismo proceso comparten los recursos (memoria, archivos, etc.), y son la unidad de planificación. Así, un proceso será un objeto estático

4 4 que posee un conjunto de recursos para una serie de hilos, que son los objetos dinámicos planificables. Los hilos siempre pertenecen a un proceso, y no tienen existencia propia independiente. Cada hilo tiene un flujo de control, una pila y un estado propio. Ya que todos los recursos, a excepción de la CPU, son gestionados por el proceso, la comunicación entre hilos de un proceso es mucho más rápida y eficiente al compartir el mismo espacio de direcciones. Cuando se produce un cambio de contexto entre hilos de distintos procesos, se produce un cambio de contexto completo. La implementación de hilos en un sistema operativo convierte a éste en mucho más rápido, pero surgen nuevos problemas de cara al programador, ya que varios hilos de un mismo proceso pueden acceder a una misma variable compartida, lo cual puede ocasionar inconsistencia en su valor. Sin embargo, a veces, la utilización de los hilos simplifica incluso la tarea del programador, dependiendo del tipo de aplicación. El modelo de programación de hilos permite ignorar los detalles de la arquitectura, como el número de procesadores, para concentrarse en el algoritmo adecuado que exprese la concurrencia. Es pues un modelo adecuado para la programación concurrente. La utilización de la concurrencia en un lenguaje de programación requiere una cierta disciplina de programación junto a la utilización de nuevas técnicas. Los componentes concurrentes de un programa pueden ejecutarse de forma paralela en un multiprocesador. Los hilos en un entorno multihilo tienen las siguientes características que pueden hacerles deseables en muchas aplicaciones que requieren multitarea: Necesitan poca memoria. Tienen un bajo coste de creación. Tienen un bajo coste de sincronización. Comparten el mismo espacio de direcciones. Pueden progresar independientemente unos de otros. Aplicaciones de los hilos Algunos programas presentan una estructura que puede hacerles especialmente adecuados para entornos multihilo. Normalmente estos casos involucran operaciones que pueden ser solapadas. La utilización de múltiples hilos, puede conseguir un grado de paralelismo que incremente el rendimiento de un programa, e incluso hacer más fácil la escritura de su código. Algunos ejemplos son: Utilización de los hilos para expresar algoritmos inherentemente paralelos. Se pueden obtener aumentos de rendimiento debido al hecho de que los hilos funcionan muy bien en sistemas multiprocesadores. Los hilos permiten expresar el paralelismo de alto nivel a través de un lenguaje de programación. Utilización de los hilos para solapar operaciones de E/S lentas con otras operaciones en un programa. Esto permite obtener un aumento del rendimiento, permitiendo bloquear a un simple hilo que espera a que se complete una operación de E/S, mientras otros hilos del proceso continúan su ejecución, evitando el bloqueo entero del proceso. Utilización de los hilos para solapar llamadas RPC salientes. Se obtiene una ganancia en el rendimiento permitiendo que un cliente pueda acceder a varios servidores al mismo tiempo en lugar de acceder a un servidor cada vez. Esto puede ser interesante para servidores especializados en los que los clientes pueden dividir una llamada RPC compleja en varias llamadas RPC concurrentes y más simples. Utilización de los hilos en interfaces de usuario. Se pueden obtener aumentos de rendimiento empleando un hilo para interactuar con un usuario, mientras se pasan las peticiones a otros hilos para su ejecución. Utilización de los hilos en servidores. Los servidores pueden utilizar las ventajas del multihilo, creando un hilo gestor diferente para cada petición entrante de un cliente. Utilización de los hilos en procesos pipeline: Se puede implementar cada etapa de una tubería o pipeline mediante un hilo separado dentro del mismo proceso. Utilización de los hilos en el diseño de un kenel multihilo de sistema operativo distribuido que distribuya diferentes tareas entre los hilos. Utilización de los hilos para explotar la potencia de los multiprocesadores de memoria compartida (sistemas fuertemente acoplados). Utilización de los hilos como soporte de aplicaciones de tiempo real acelerando los tiempos de respuesta para los eventos asíncronos a través de la gestión de señales. Algunas de estas técnicas pueden ser implementadas usando múltiples procesos. Los hilos son sin embargo más interesantes como solución porque: Los procesos tienen un alto coste de creación. Los procesos requieren más memoria. Los procesos tienen un alto coste de sincronización. Compartir memoria entre procesos es más complicado, aunque compartir memoria entre hilos tiene sus problemas. Los hilos se crearon para permitir combinar el paralelismo con la ejecución secuencial y el bloqueo de llamadas al sistema. Las llamadas al sistema con bloqueo facilitan la programación, y el paralelismo obtenido mejora el rendimiento. Ejemplo de servidor de archivos Consideremos el siguiente ejemplo de un servidor de archivos, en distintas implementaciones: 1) Servidor con varios hilos: - El hilo servidor, lee las peticiones de trabajo del buzón del sistema. - Examina la solicitud, y selecciona un hilo trabajador inactivo (bloqueado), al cual envía la solicitud mediante algún tipo de mensaje. Después el hilo servidor despierta al hilo trabajador dormido (por ejemplo, mediante un SIGNAL en el semáforo donde duerme). - Cuando el hilo trabajador despierta, consulta la cache del bloque de memoria compartida entre todos los hilos, para verificar que puede dar servicio a la solicitud. Si no,

5 5 envía una solicitud al disco para obtener el bloque de disco correspondiente (si se trata de una operación de lectura), y se duerme a la espera. Se llama al planificador, y se inicializa otro hilo, que podría ser el servidor para pedir más trabajo, o bien otro trabajador listo para realizar un trabajo. Pero veamos como se implementaría el servidor de archivos sin hilos. 2) Servidor con un único proceso (único hilo), en el cual el proceso servidor realiza todo el tratamiento cíclicamente: - obtener una solicitud - examinar el tipo de solicitud - servir la solicitud, y volver al principio. Mientras el proceso espera al disco, está inactivo y no procesa otras solicitudes. Si el servidor de archivos se ejecuta en una máquina dedicada, como suele ser habitual, la CPU estará inactiva, mientras se espera al disco, produciendo un menor número de solicitudes/sg. servidas. Así pues, los hilos aumentan el rendimiento de una forma importante, y sin embargo cada uno de ellos también se ejecuta de forma secuencial. 3) Servidor como máquina de estados finitos: - obtener una solicitud - examinar el tipo de solicitud - Si se encuentra en la caché, perfecto, sino se envía un mensaje al disco, y en vez de bloquearse, se registra el estado de la solicitud actual en una tabla - Después se consulta la tabla y se obtiene el siguiente mensaje, que puede ser una solicitud de un nuevo trabajo, o una respuesta del disco con respecto a una operación pendiente anterior. - Si es un nuevo trabajo, se comienza su resolución. Y si es una respuesta del disco, se localiza la información necesaria en la tabla y se procesa la respuesta. Como no se puede enviar un mensaje y bloquearse a la espera, no se puede utilizar RPC, así pues las primitivas deben ser del tipo send y receive sin bloqueo. Sin embargo, en este diseño se pierde el modelo "de proceso secuencial" que teníamos en los casos anteriores. Necesitamos guardar el estado y restaurarlo en la tabla para cada mensaje enviado o recibido. En el fondo lo que estamos realizando es una simulación de varios hilos y sus pilas de una manera complicada. El funcionamiento es el de una máquina de estados finitos que obtiene un evento y reacciona según el estado en el que se encuentre. Los hilos, por tanto, mantienen la idea de procesos secuenciales que realizan llamadas al sistema con bloqueo (por ejemplo, RPC), y sin embargo permiten el paralelismo. Las llamadas al sistema con bloqueo facilitan la programación, y el paralelismo mejora el rendimiento del sistema. En el 2º caso, el servidor de un único hilo emplea llamadas con bloqueo, pero tiene un bajo rendimiento al no conseguir el paralelismo. El 3º caso, logra un mejor rendimiento mediante el paralelismo conseguido por la máquina de estados finitos, pero emplea llamadas sin bloqueo que dificultan la programación. Otras aplicaciones de los hilos Los hilos también pueden ser muy útiles en la implementación no sólo de procesos servidores, sino de procesos clientes. Por ejemplo, si un cliente quiere copiar un archivo en varios servidores, puede hacer que un hilo se comunique con cada servidor. También se pueden emplear los hilos en el manejo de señales, como por ejemplo las interrupciones del teclado: se puede dedicar un hilo a la espera de señales, en vez de que éstas interrumpan el proceso. Normalmente, el hilo se bloquea a la espera de señales, y cuando se produce una señal, despierta y la procesa. Esto puede eliminar la necesidad de interrupciones a nivel de usuario. Otra razón de peso que justifica la utilización de hilos, y que no tiene relación con las RPCs o la comunicación, se basa en que muchas tareas son más fáciles de programar mediante procesos paralelos, ya que tienen una naturaleza inherentemente paralela. Como ejemplo encontramos el problema del productor-consumidor. Este problema es de naturaleza paralela, ya que de esta forma es más fácil su diseño, al margen de que en la realidad el productor y el consumidor se ejecuten o no de forma paralela. Además, dada la necesidad de compartir un buffer común, este problema se adapta perfectamente al caso de los hilos. Como última justificación, en un sistema multiprocesador, es posible que los hilos de un mismo proceso se ejecuten realmente en paralelo, en varias CPU. Un programa bien diseñado y que emplee hilos funcionará tanto en una CPU con hilos compartidos, como en un verdadero multiprocesador, lo que hace al diseño independiente de la implementación. El empleo de los hilos en el desarrollo de aplicaciones puede tener la recompensa de incrementar el rendimiento de la aplicación. Un incremento en el rendimiento de la aplicación puede significar una ventaja competitiva, sin embargo la robustez de la aplicación y la portabilidad de la misma, han de tenerse también en consideración. Desarrollar aplicaciones robustas basadas en hilos es posible con un correcto entrenamiento y con herramientas que ayuden al mantenimiento del programa. Desarrollar aplicaciones portables será posible cuando la industria se ciña al nuevo estándar POSIX c. Organización de los hilos de un proceso Otra forma de estudiar las posibilidades de emplear los hilos es pensar en términos de modelos de programación. La programación multihilo es especialmente útil en algunos modelos de programación. Los hilos se pueden organizar de distintas formas para que cooperen entre sí en la resolución de un problema. Existen una serie de modelos típicos de organización de los hilos de un proceso. Veamos cada modelo aplicado al ejemplo del servidor de archivos: Modelo servidor/trabajador: En este modelo un hilo funciona como supervisor asignando tareas a los hilos trabajadores. Después de que el trabajador ha finalizado su tarea, lo indica al supervisor o es el supervisor quien lo comprueba por sí mismo, para después recibir una nueva tarea. Es el modelo empleado en el primer ejemplo del servidor de archivos. Un hilo servidor que obtiene las solicitudes y las redirige a los hilos trabajadores, que realizan el servicio.

6 6 Combinación de modelos: En este caso se emplea una mezcla con más de un modelo. Diseño de un paquete de hilos Modelo de cola de trabajo: Este modelo es una variante del modelo servidor/trabajador. En este modelo las tareas son colocadas por el servidor o supervisor en una cola que es accedida por los trabajadores hasta que se vacía. Modelo de equipo: En este modelo múltiples hilos trabajan juntos en una tarea simple. Cada hilo realiza una parte de la tarea, como una casa en la que cada pintor pinta una parte de la misma. Todos los hilos son iguales, y cada uno obtiene y procesa sus propias solicitudes. No existe un hilo servidor. Se puede asociar una cola de trabajo a cada tipo de solicitud, de tal forma que existan tantas categorías de hilos como tipos de solicitud. Un hilo sólo dará servicio a un tipo de solicitud, teniendo preferencia las solicitudes en espera en la cola correspondiente frente las solicitudes del buzón del sistema. Modelo de tubería o entubamiento o pipelining: En este modelo se emplea el esquema de una cadena de montaje, con cada hilo realizando un determinado paso en la tarea. Tan pronto como un hilo termina un paso de la tarea, otro hilo trabaja en ella. Cuando un hilo termina un paso, puede empezar a trabajar en el mismo paso de otra tarea. En este modelo los hilos trabajan de forma encadenada. El primer hilo genera ciertos datos, y los transfiere al siguiente hilo que realizará cierto procesamiento sobre los mismos, y generará nuevos datos de salida. El proceso se puede repetir con más hilos encadenados. Los datos pasan de un hilo a otro, y en cada paso sufren cierto procesamiento. Esta solución puede ser apropiada en algunos problemas como el del productor-consumidor o en las líneas de comandos de UNIX, aunque no parece adecuado para el problema del servidor de archivos. Es posible implementar una biblioteca de hilos que soporte planificación preemptiva, rápidos cambios de contexto entre hilos, secciones críticas pequeñas, evite el crecimiento ilimitado de la pila, emplee pocas llamadas al sistema, y proporcione un interfaz independiente del lenguaje. Un paquete de hilos consiste de un conjunto de primitivas relacionadas con la gestión de los hilos, y disponibles para que el programador realice aplicaciones multihilo. El paquete de hilos también se encargará de gestionar, controlar, crear y destruir los hilos que la aplicación multihilo requiere para su ejecución. Los paquetes de hilos suelen tener también llamadas para especificar el tipo de algoritmo de planificación deseado para los hilos: round-robin, prioridades, etc., así como establecer las prioridades en su caso. Para maximizar el rendimiento de la biblioteca de hilos, las llamadas al kernel del sistema operativo deben ser minimizadas. La sobrecarga asociada cuando se entra y se sale del kernel del sistema hace que las llamadas al sistema sean operaciones muy costosas. La mayoría de las llamadas que debe realizar el paquete estarán relacionadas con la inicialización de la biblioteca y otra serie de etapas que no sean críticas en tiempo. Existen dos formas de gestionar los hilos: a) Diseño de Hilos Estáticos: El numero de hilos se fija al escribir el programa o durante la compilación. Cada hilo tiene asociada un pila fija. Es una alternativa simple pero inflexible. b) Diseño de Hilos Dinámicos: Se permite la creación y destrucción de hilos durante la ejecución. En este modelo un proceso se inicia con un sólo hilo (de manera implícita), pero puede crear más hilos posteriormente. Este suele ser el diseño habitual empleado en los paquetes de hilos actuales. Existe una llamada para la creación de hilos que determina el programa principal del hilo, para ello se pasa a la llamado un puntero al procedimiento principal, un tamaño para la pila del hilo, y otra serie de parámetros, como puede ser la prioridad de planificación. La llamada devuelve un identificador del hilo. La sintaxis abstracta de la llamada de creación de hilos es id_hilo CreateThread(puntero_procedimiento, tamaño_pila, Parametros...) Un hilo puede finalizar su ejecución por dos razones (al igual que un proceso): la terminación natural de su trabajo o su eliminación desde el exterior. Estructura básica El estándar POSIX Threads especifica un modelo de hilos dirigido por prioridades con políticas de planificación preemptivas, gestión de señales, y primitivas para proporcionar exclusión mutua así como espera sincronizada. El diseño de un paquete de hilos suele estar influenciado por las restricciones impuestas por el estándar POSIX Threads (si se desea seguir dicho estándar, caso habitual) y el tipo de plataforma sobre la que se va a implementar. Normalmente el diseño del paquete intenta reducir al mínimo la cantidad de código dependiente de la plataforma, y se suele aislar en

7 7 módulos concretos, de forma que la biblioteca sea adaptable a nuevas plataformas. En la mayoría de las implementaciones, el interfaz consiste en una biblioteca C con puntos de entrada enlazables, de forma que pueda ser compilada para generar un interfaz de lenguaje independiente. Este es el caso de la implementación Pthreads realizada por Frank Mueller como base del proyecto PART (Portable Ada Run-Time). Un interfaz permite que los programas empleen los servicios de la biblioteca independientemente del lenguaje que empleemos. En el caso del lenguaje C, las rutinas de la biblioteca son utilizables directamente, mientras que en otros lenguajes es necesario crear un interfaz entre el lenguaje y la biblioteca de hilos. En algunos diseños de paquetes de hilos, el código de las rutinas de la biblioteca se ejecuta normalmente en modo usuario, aunque las secciones críticas se ejecutan en un modo protegido o kernel de la biblioteca (no confundir con el modo kernel del sistema), que es un modo especial que garantiza la exclusión mutua entre hilos. Estas implementaciones suelen emplear rutinas de la biblioteca estándar del sistema y algunas llamadas al kernel del sistema. Los objetivos de diseño que deben prevalecer son: Planificación preemptiva: Políticas de planificación como Round-Robin y señales o eventos asíncronos junto con prioridades, sólo pueden ser soportados mediante un diseño de kernel preemptivo. Cambios de contexto rápidos: El cambio de contexto debe ser la única causa por la cual el control es transferido de un hilo a otro, de forma que se debe intentar reducir la sobrecarga del cambio de contexto. Impedir el crecimiento de pila ilimitado: Si se produce un evento asíncrono mientras se ejecuta un gestor de interrupciones, otro gestor puede ser introducido en la pila y así hasta el infinito. Este caso se debe evitar mediante alguna solución particular. Sincronización Como los hilos comparten el espacio de direcciones, comparten las variables globales. El acceso a dichas variables se realiza generalmente mediante regiones críticas, para evitar que varios hilos tengan acceso a los mismos datos al mismo tiempo. Por ello es necesario sincronizar el acceso a los recursos compartidos por los hilos de un proceso. La implementación de las regiones críticas es más sencilla utilizando semáforos, monitores u otras construcciones similares. El estándar POSIX Threads especifica un mútex como estructura de datos para garantizar el acceso exclusivo a datos compartidos, y variables de condición para realizar la sincronización entre hilos. Otros métodos de sincronización tales como semáforos contadores pueden implementarse empleando estas primitivas. Normalmente los paquetes de hilos implementan las siguientes técnicas: Mútex Un mútex consiste en una especie de semáforo binario con dos estados, cerrado y no cerrado. Un mútex es un objeto que permite a los hilos asegurar la integridad de un recurso compartido al que tienen acceso. Tiene dos estados: bloqueado y desbloqueado. Sobre un mútex se pueden realizar las siguientes operaciones: LOCK: Intenta cerrar el mútex. Si el mútex no está cerrado, se cierra, todo ello en una acción atómica. Si el mútex está cerrado, el hilo se bloquea. Si dos hilos intentan cerrar el mútex al mismo tiempo, cosa que sólo puede pasar en un multiprocesador real, uno de ellos lo consigue y el otro no, bloqueándose. La forma de regular esto depende de la implementación. UNLOCK: Elimina o libera el cierre del mútex. Si existe uno o más hilos esperando por el mútex, se desbloquea exactamente uno, y el resto permanece bloqueado a la espera. TRYLOCK: Intenta cerrar un mútex. Se devuelve un código indicando el resultado del intento de bloqueo: OK (se pudo cerrar) o ERROR (el mútex estaba cerrado, pero el hilo no se bloqueó a la espera). Antes de acceder a un recurso compartido un hilo debe bloquear un mútex. Si el mútex no ha sido bloqueado antes por otro hilo, el bloqueo es realizado. Si el mútex ha sido bloqueado antes, el hilo es puesto a la espera. Tan pronto como el mútex es liberado, uno de los hilos en espera a causa de un bloqueo en el mútex es seleccionado para que continúe su ejecución, adquiriendo el bloqueo. Un ejemplo de utilización de un mútex es aquél en el que un hilo A y otro hilo B están compartiendo un recurso típico, como puede ser una variable global. El hilo A bloquea el mútex, con lo que obtiene el acceso a la variable. Cuando el hilo B intenta bloquear el mútex, el hilo B es puesto a la espera puesto que el mútex ya ha sido bloqueado antes. Cuando el hilo A finaliza el acceso a la variable global, desbloquea el mútex. Cuando esto suceda, el hilo B continuará la ejecución adquiriendo el bloqueo, pudiendo entonces acceder a la variable. Hilo A: Hilo B: lock(mutex) lock(mutex) acceso al recurso acceso al recurso unlock(mutex) unlock(mutex) Un hilo puede adquirir un mútex no bloqueado. De esta forma, la exclusión mutua entre hilos del mismo proceso está garantizada, hasta que el mútex es desbloqueado permitiendo que otros hilos protejan secciones críticas con el mismo mútex. Si un hilo intenta bloquear un mútex que ya está bloqueado, el hilo se suspende. Si un hilo desbloquea un mútex y otros hilos

8 8 están esperando por el mútex, el hilo en espera con mayor prioridad obtendrá el mútex. Para simplificar las implementaciones, normalmente un hilo no puede ser cancelado cuando tiene cancelación activada y controlada, y se suspende debido a la espera del mútex, con el fin de garantizar un estado determinista del mútex en los gestores de limpieza. Un mútex debe ser bloqueado durante el menor tiempo posible para minimizar la espera. Por ejemplo, se debe proteger el acceso a estructuras de datos compartidas entre hilos mediante mútex. Pero no se debe bloquear un mútex, realizar una acción que puede provocar la suspensión del hilo, y después desbloquear el mútex, porque se puede producir la espera durante un largo periodo mientras se posee el mútex. Variables de condición Una variable de condición es un objeto que permite que los hilos se ejecuten en un secuencia ordenada. Los hilos pueden esperar a que se cumpla una cierta condición, o pueden indicar a otros hilos que se ha producido una cierta condición, liberando uno o más hilos de la condición de espera. Existe un mútex y un predicado asociados con una variable de condición. El predicado es una variable específica de la aplicación comprobada por los hilos, indicando que algún tipo de condición está lista o no. El predicado es necesario porque la variable de condición misma es opaca, siendo usado en las operaciones wait y signal. El mútex de la variable de condición asegura que un hilo como máximo está accediendo al predicado y entrando en un estado de espera o enviando una señal basada en su valor. Típicamente, una variable de condición es empleada para indicar cuando un hilo debe comenzar a trabajar en una tarea. Esto puede ser útil para implementar el modelo de hilos de trabajo en equipo, haciendo que los hilos trabajadores esperen por una variable de condición usada como un flag para indicar el instante de comienzo. En el modelo de tubería se puede emplear una variable de condición para indicar que la etapa anterior de una tarea ha sido completada por algún hilo. Un ejemplo de utilización de una variable de condición es aquel en el que un hilo A bloquea un mútex asociado con una variable de condición. Eventualmente el hilo A adquiere el bloqueo de este mútex, procediendo entonces a acceder al predicado. Si el predicado indica un estado deseado, el hilo A procederá a desarrollar la tarea X y desbloqueará el mútex. Si no, el hilo A entrará en un estado de espera, pero la operación wait realizará automáticamente el desbloqueo del mútex. El hilo B bloquea el mútex asociado con la variable de condición después de haber completado la tarea Y. Eventualmente, el hilo B adquirirá el bloqueo de este mútex, procediendo entonces a acceder al predicado. El hilo B pondrá el predicado en el estado ready, indicando con signal que el predicado está listo y desbloqueando el mútex. Si el hilo A estaba esperando en la variable de condición, la indicación signal emitida por el hilo B provocará que el hilo A continúe su ejecución. Supongamos la secuencia en la que el hilo A sólo realiza la tarea X después de que el hilo B haya realizado la tarea Y. El hilo B indica que ha realizado la tarea Y empleando una variable de condición accedida por ambos hilos A y B. Hilo A: Hilo B: lock(mutex) Realizar Tarea Y while (!predicado) lock(mutex) wait(var_condic, mutex) Realizar Tarea X unlock(mutex) predicado = TRUE signal(var_condic) unlock(mutex) Para permitir la sincronización entre hilos y la suspensión durante un largo intervalo de tiempo, se emplean las variables de condición. Una variable de condición está asociada con un mútex y un predicado basado en datos compartidos. Cuando un hilo necesita sincronizarse con otro, bloquea el mútex, comprueba el predicado y, si el predicado se evalúa a falso, se suspende en la variable de condición. Cuan el hilo es reactivado, vuelve a evaluar el predicado y así hasta que el predicado se hace cierto. La evaluación nuevamente del predicado es esencial ya que las reactivaciones en un multiprocesador y las reactivaciones debidas a eventos asíncronos pueden causar que el hilo continúe su ejecución mientras el predicado permanece a falso, debido a que las operaciones no son atómicas. Cuando un hilo entra en una espera condicional con el mútex asociado bloqueado, el mútex es desbloqueado y el hilo suspendido en una sola operación atómica. De forma similar, el mútex es bloqueado nuevamente cuando el hilo continua su ejecución, de forma atómica. Así pues, el mútex asociado está siempre en un estado conocido, incluso cuando las señales interrumpen una espera condicional, ya que el mútex es readquirido antes de que se inicie la ejecución de cualquier gestor de interrupciones. Una variable de condición es "señalada" por un hilo después de que el hilo cambie el estado de algún dato compartido permitiendo que el predicado asociado se haga cierto. Cuando una variable de condición es señalada, al menos uno de los hilos bloqueados en ella pasa al estado preparado. Si más de un hilo está bloqueado en la variable de condición, el hilo con mayor prioridad pasará al estado preparado. En particular, en un sistema multiprocesador, puede ser más eficiente desbloquear más de un hilo a la espera de la condición. Una variable de condición es una variable similar a la variable de condición empleada en la implementación de los monitores como técnica de sincronización. Se suele asociar un mútex a una variable de condición cuando ésta se emplea. Cuando se espera por una variable de condición, se indica el mútex bloqueado asociado a la sección crítica a la que se desea acceder cuando se cumpla la condición. De esta forma la variable de condición y el mútex cooperan en la protección de una región crítica condicional. - El mútex se emplea para realizar un cierre a corto plazo, normalmente para proteger el acceso a las regiones críticas. - La variable de condición se utiliza para una espera a largo plazo, en espera de algún recurso no disponible. Por ello cuando se espera por una condición, se libera el mútex de acceso a la región critica, pero se vuelve a bloquear dicho mútex cuando se despierta la variable de condición. Variables globales El problema de compartir las variables globales por varios hilos puede provocar que generemos valores incorrectos en sus valores, debido a la indeterminación

9 9 del hilo que se ejecutará en cada momento. Existen diversas soluciones a este problema: 1) Prohibir las variables globales: Es algo ideal, pero genera conflictos con el software existente. 2) Asignar variables globales particulares a cada hilo: Cada hilo tiene su propia copia de la variable global, lo que evita los conflictos. Se crea pues un nivel más de visibilidad correspondiente a las variables visibles por todos los procedimientos de un hilo. El problema es que no todos los lenguajes tienen formas de expresar este tipo de variables. Una solución es asignar un bloque de memoria a las variables globales y transferirla a cada procedimiento del hilo como un parámetro adicional. No es una solución elegante, pero funciona. 3) Crear nuevos procedimientos de biblioteca, para crear, asignar y leer los valores de estas variables globales en un hilo. Esta es la forma que suelen adoptar la mayoría de los paquetes de hilos. Las llamadas, de forma abstracta, podrían ser: - create_global("puntero_variable") = Asigna un espacio de almacenamiento para un puntero de una variable en un área especial reservada para el hilo que hizo la llamada. El hilo que hizo la llamada es el único que puede acceder a la variable. Si otro hilo crea una variable global con el mismo nombre obtiene un espacio de almacenamiento distinto, lo que evita conflictos con el ya existente. - set_global("puntero_variable", &valor) = Almacena el valor de un puntero en el espacio de almacenamiento reservado anteriormente. - puntero_variable = read_global("puntero_variable") = Devuelve la dirección almacenada en la variable global, para tener acceso al valor del dato. Implementación de un paquete de hilos Aunque cada paquete de hilos puede tener una implementación distinta, existen dos formas básicas de implementación de los hilos, y una forma mixta: 1. Implementación a nivel usuario, en forma de paquete o biblioteca de hilos, donde toda la funcionalidad es parte del programa de usuario. Esta implementación puede ser más eficiente, ya que no se necesita entrar al kernel en cada llamada, pero complica la gestión de señales y otras operaciones con los hilos. Además se necesitan dos planificadores, un planificador de procesos (a nivel kernel) y un planificador de hilos (en el paquete de hilos, a nivel usuario). Existen sin ningún soporte del kernel y mantienen todo su estado en el espacio de usuario. El kernel no conoce su existencia por lo que no pueden ser planificados para ejecutarse en múltiples procesadores en paralelo. 2. Implementación a nivel kernel, donde toda la funcionalidad es parte del kernel del sistema operativo. Esta implementación simplifica el control sobre las operaciones de los hilos y la gestión de señales, pero añade gran sobrecarga al ser necesario entrar y salir del kernel en cada llamada. Este tipo de sistemas son conocidos como sistemas puros o sistemas de un solo nivel, ya que el kernel es el responsable de planificar todos los hilos. 3. Implementación mixta, que consiste en implementar una biblioteca de hilos, pero apoyado en un modelo de hilos de nivel kernel, que permite la ejecución de los hilos de usuario. Estos sistemas son conocidos como sistemas híbridos o sistemas a dos niveles. El kernel coopera con el paquete de hilos de nivel usuario en la planificación. Normalmente el kernel planifica procesos ligeros, llamados abreviadamente LWPs, y la biblioteca de hilos planifica hilos de usuario sobre LWPs. Paquete de hilos de nivel usuario El paquete se implementa en el espacio de usuario, sin que el núcleo conozca su existencia. El núcleo sigue manejando procesos con un único hilo. Figura 3-9 Paquete de hilos a nivel de usuario. Los hilos se ejecutan en la parte superior de un sistema de tiempo de ejecución, que consiste en un conjunto de procedimientos que gestionan los distintos hilos. Cuando un hilo ejecuta una llamada al sistema, se bloquea (duerme), realiza una operación en un mútex, o realiza alguna acción que provoca su suspensión, en realidad llama a un procedimiento del sistema de tiempo de ejecución. Este procedimiento es el que verifica si se debe suspender el hilo. En ese caso, almacena los registros del hilo en una tabla, localiza un nuevo hilo no bloqueado para ejecutar, y restaura los registros del nuevo hilo a partir de los valores almacenados en la tabla. Se establecen también los valores del puntero de pila y de programa, y entonces el hilo vuelve a ejecutarse. Si la máquina tiene una instrucción para almacenar los registros y otra para cargarlos, entonces todo el intercambio de hilos se puede realizar en una sola operación. Esta conmutación entre hilos es muy superior, en velocidad, a la conseguida si el intercambio se realizase a nivel del núcleo. En un sistema operativo que soporta hilos a nivel de usuario, una aplicación puede ser 'multithreaded', esto es, múltiples hilos de ejecución pueden existir dentro de un proceso. Normalmente, una limitación de los hilos de usuario es que sólo un hilo, representando una porción de todo el programa, puede ejecutarse en un momento dado. Cuando un proceso formado por hilos es planificado, el contexto de un hilo de usuario se enlaza con el proceso, y el proceso ejecuta dicho hilo. Si un hilo se bloquea o finaliza, otro hilo del mismo proceso puede ser planificado en su lugar, con lo cual no se pierde el quantum de tiempo asignado. Los hilos de usuario pueden ser creados por programadores de aplicaciones usando los APIs de hilos proporcionados por una biblioteca de hilos. Estos APIs permiten a los programadores crear, finalizar, y sincronizar los hilos de un proceso. La librería de hilos puede también contener un planificador para los hilos de usuario. Los hilos de usuario no son directamente visibles por el kernel, son visibles sólo en el espacio de usuario. Así pues, un hilo de usuario debe estar asociado con un entidad del kernel planificable (como un proceso) para tener acceso al procesador. En este