Gestión de Procesos Hilos.

Presentación del tema: "Gestión de Procesos Hilos."— Transcripción de la presentación:

1 Gestión de Procesos Hilos

2 Estructura de los Hilos
Un hilo o proceso ligero (LWP, lightweight process), es una unidad básica de utilización de la CPU Consiste en: Un contador de programa Un conjunto de registros y Un espacio de pila. Además comparte con sus hilos pares la sección de código, sección de datos y recursos del sistema operativo como archivos abiertos y señales (tarea) Un proceso tradicional o pesado es igual a una tarea con un solo hilo. Un hilo debe estar en una y sólo una tarea. El extenso compartir hace que la conmutación de la CPU entre hilos pares, y la creación de hilos, sea económica en comparación con las conmutaciones de contexto entre procesos pesados. Aunque la conmutación de contexto de hilos también requiere un cambio de conjunto de registros, no hay que realizar operaciones relacionadas con la gestión de memoria. Al igual que cualquier entorno de procesamiento paralelo, el multihilado de un proceso puede introducir problemas de control de concurrencia que requieren el uso de secciones críticas o cerrojos.

3 Hilos a nivel de Usuario
Algunos sistemas implementan hilos en el nivel de usuario en bibliotecas del usuario. No se requieren llamadas al sistema, así que la conmutación de hilos no necesita invocar el sistema operativo ni causar una interrupción para pasar al núcleo. Bloquear un hilo y conmutar a otro es una solución razonable y se puede manejar muchas solicitudes de forma eficiente. Los hilos en el nivel de usuario tienen desventajas. Por ejemplo, si el núcleo es monohilado, cualquier hilo en el nivel de usuario que ejecute una llamada al sistema hará que toda la tarea espere hasta que la llamada regrese.

4 Funcionalidad de los Hilos
Los hilos operan, en muchos sentidos, de la misma forma que los procesos. Los hilos pueden estar en uno de varios estados: listo, bloqueado, en ejecución o terminado. Al igual que los procesos, los hilos comparten la CPU, y sólo hay un hilo activo (en ejecución) en un instante dado. Un hilo dentro de un proceso se ejecuta secuencialmente, y cada hilo tiene su propia pila y contador de programa.

5 Funcionalidad de los Hilos (cont)
Los hilos pueden crear hilos hijos, y se pueden bloquear en espera a que termine la ejecución de llamadas al sistema Si un hilo se bloquea, otro puede ejecutarse. A diferencia de los procesos, los hilos no son independientes entre sí. Todos los hilos pueden acceder a todas las direcciones de la tarea, un hilo puede leer la pila de cualquier otro hilo, o escribir sobre ella. La protección no deberá ser necesaria, pues el dueño de una tarea con múltiples hilos tiene que ser un usuario único. Los hilos, en este caso, probablemente estarían diseñados para ayudarse mutuamente, y por tanto no requerirían protección mutua.

6 Funcionalidad de los Hilos (cont)
En el caso del proceso servidor de archivos bloqueado en el modelo de proceso único, ningún otro proceso servidor puede ejecutarse en tanto el primer proceso no se desbloquee. En contraste, en el caso de una tarea que contiene múltiples hilos, mientras un hilo servidor está bloqueado y esperando, podría ejecutarse un segundo hilo de la misma tarea. La cooperación de múltiples hilos que forman parte del mismo trabajo confiere ventajas de mayor rendimiento y mejor desempeño. En el caso del problema de productores y consumidores, requieren compartir un buffer común, se beneficiarían del uso de hilos: el productor y el consumidor podrían ser hilos de una tarea. Se requiere muy poco gasto extra para conmutar entre ellos En un sistema multiprocesador, se podrían ejecutar en paralelo en dos procesadores para lograr una eficiencia máxima.

7 Funcionalidad de los Hilos (cont)
La abstracción que presenta un grupo de procesos ligeros es la de múltiples hilos de control asociados a varios recursos compartidos. Dos alternativas en lo tocante a los hilos: El núcleo puede apoyar a los hilos (como en los sistemas operativos Mach y OS/2). En este caso, se cuenta con un conjunto de llamadas al sistema similares a las que se usan con procesos. Otra alternativa es apoyar los hilos sobre el núcleo, a través de una serie de llamadas de biblioteca en el nivel de usuario (como se hace en el Proyecto Andrew de CMU).

8 Funcionalidad de los Hilos (cont)
Consideremos dos procesos, uno con un hilo (proceso a) y otro con 100 hilos (proceso b). Cada proceso generalmente recibe el mismo número de porciones de tiempo, de modo que el hilo del proceso a se ejecutará con una velocidad 100 veces mayor que un hilo del proceso b. En los sistemas con hilos apoyados por el núcleo, la conmutación entre los hilos consume más tiempo porque el núcleo debe realizarla (a través de una interrupción). Por otro lado, cada hilo se puede planificar de forma independiente, así que el proceso b recibiría 100 veces más tiempo de CPU que el proceso a Además, el proceso b podría tener 100 llamadas al sistema en curso de manera concurrente, logrando mucho más de lo que el mismo proceso lograría en un sistema que sólo tuviera soporte de hilos en el nivel de usuario.

9 Funcionalidad de los Hilos (cont)
Dadas las concesiones que deben hacerse en cada uno de estos enfoques del uso de hilos, algunos sistemas adoptan un enfoque híbrido en el que se implementan tanto hilos en el nivel de usuario como apoyados por el núcleo (Solaris 2) La popularidad de los hilos está creciendo porque tienen algunas de las características de los procesos pesados pero se pueden ejecutar con mayor eficiencia Existen muchas aplicaciones en las que esta combinación es útil. Por ejemplo, algunas implementaciones del núcleo de UNIX son monotareas ( sólo una tarea puede estar ejecutando código del núcleo en un momento dado) Con esto se evitan muchos problemas, como la sincronización del acceso a datos (poniendo cerraduras a las estructuras de datos mientras se están modificando) y así se permite solo a un proceso efectuar la modificación

10 Funcionalidad de los Hilos (cont)
El sistema Mach, en cambio, es multihilado y permite al núcleo atender muchas solicitudes simultáneamente. En este caso, los hilos mismos son sincrónicos: otro hilo del mismo grupo sólo puede ejecutarse si el hilo que se está ejecutando actualmente le cede el control. Desde luego, el hilo actual sólo cedería el control si no está modificando datos compartidos. En los sistemas en que los hilos son asincrónicos es preciso emplear algún mecanismo de cerraduras explícito, al igual que en los sistemas en que múltiples procesos comparten datos..

11 Comunicación entre Procesos
En caso de procesos cooperativos en torno de memoria compartida, se requiere que estos procesos compartan una reserva de buffers común El programador de la aplicación debe escribir explícitamente el código para implementar el buffer Otra forma de lograr el mismo efecto es que el sistema operativo proporcione los medios para que procesos cooperativos se comuniquen unos con otros a través de un mecanismo de comunicación entre procesos (IPC, interprocess communication). La IPC ofrece un mecanismo que permite a los procesos comunicarse y sincronizar sus acciones. La mejor forma de proveer la comunicación entre procesos es mediante un sistema de mensajes. Cabe señalar que los esquemas de comunicación por memoria compartida y por transferencia de mensajes no son mutuamente exclusivos, y podrían utilizarse simultáneamente dentro de un mismo sistema operativo o incluso dentro de un mismo proceso.

12 IPC: Estructura básica
La función de un sistema de mensajes es permitir a los procesos comunicarse entre sí sin tener que recurrir a variables compartidas. El IPC ofrece por lo menos dos operaciones: enviar(mensaje) (send) y recibir(mensaje) (receive). Los mensajes que un proceso envía pueden ser de tamaño fijo o variable SI solo es posible enviar mensajes de tamaño fijo, la implementación física es sencilla. Sin embargo, esta restricción dificulta la tarea de programación Por otro lado, los masajes de tamaño variable requieren una implementación física mas compleja, aunque simplifican la tarea de programación.

13 IPC: Estructura básica (cont)
Si los procesos P y Q quieren comunicarse, deberán enviarse mensajes a través de un enlace de comunicación entre ellos. Este enlace se puede implementar de diversas maneras, se verá los problemas de su implementación lógica, y sus propiedades lógicas. Preguntas básicas para la implementación: ¿Cómo se establecen los enlaces? ¿Un enlace puede estar asociado a más de dos procesos? ¿Cuántos enlaces puede haber entre cada par de procesos? ¿Qué capacidad tiene un enlace? Es decir, ¿el enlace tiene espacio de buffer? De ser así, ¿cuánto? ¿Qué tamaño tienen los mensajes? ¿El enlace puede dar cabida a mensajes de tamaño variable o sólo de tamaño fijo? ¿El enlace es unidireccional o bidireccional? Es decir, si existe un enlace entre P y Q, ¿los mensajes pueden influir sólo en una dirección (digamos, sólo de P a Q) o en ambas direcciones?

14 IPC: Estructura básica (cont)
La definición de unidireccional se debe plantear con más cuidado, ya que un enlace podría estar asociado a más de dos procesos Un enlace es unidireccional sólo si cada proceso conectado al enlace puede enviar o recibir, pero no ambas cosas, y cada enlace tiene por lo menos un proceso receptor conectado a él. Métodos y/o tipos para implementar lógicamente un enlace y las operaciones de enviar/recibir: Comunicación directa o indirecta Comunicación simétrica o asimétrica Uso de buffers automático o explícito Envío por copia o envío por referencia Mensajes de tamaño fijo o variable

15 IPC: Comunicación Directa
En comunicación directa, cada proceso que desea comunicarse debe nombrar explícitamente el destinatario o el remitente Las primitivas enviar y recibir como sigue: enviar(P, mensaje). Enviar un mensaje al proceso P. recibir(Q, mensaje). Recibir un mensaje del proceso Q. El enlace de comunicación de este esquema tiene las siguientes propiedades: Establecimiento automático del enlace entre cada par de procesos que desean comunicarse. Los procesos sólo necesitan conocer la identidad del otro para comunicarse. El enlace se asocia a exactamente dos procesos. Entre cada par de procesos sólo existe un enlace. El enlace puede ser unidireccional o bidireccional.

16 Comunicación Directa: Productor y Consumidor
Para que los procesos productores y consumidores puedan ejecutarse de forma concurrente, el productor produce un elemento mientras el consumidor está consumiendo otro elemento Cuando el productor termina de generar un elemento, envía ese elemento al consumidor. El consumidor obtiene dicho elemento por medio de la operación recibir Si un elemento todavía no se ha producido, el proceso consumidor debe esperar hasta que se produce.

17 Comunicación Directa: Productor y Consumidor

18 Comunicación Simétrica o Asimétrica
El esquema anterior tiene una simetría de direccionamiento, el emisor como receptor necesitan nombrar al otro para comunicarse En la asimetría de direccionamiento. Sólo el emisor nombra al destinatario y el destinatario no está obligado a nombrar al emisor. Las primitivas enviar y recibir: enviar(P, mensaje). Enviar un mensaje al proceso P. recibir(id, mensaje). Recibir un mensaje de cualquier proceso; la variable id es el nombre del proceso con el que hubo comunicación. La desventaja de ambos esquemas (simétrico y asimétrico) es la limitada modularidad de las definiciones de proceso que se obtienen Para cambiar el nombre de un proceso podría ser necesario examinar todas las demás definiciones de procesos para cambiarlas al nuevo Esta situación no es deseable desde el punto de vista de la compilación separada.

19 Comunicación Indirecta
En la comunicación indirecta, los mensajes se envían a, y se reciben de, buzones (también llamados puertos). Un buzón puede considerarse en abstracto como un objeto en el que los procesos pueden colocar mensajes y del cual se pueden sacar mensajes Cada buzón tiene una identificación única. En este esquema, un proceso se puede comunicar con otro a través de varios buzones distintos. Dos procesos pueden comunicarse sólo si comparten un buzón Las primitivas enviar y recibir se definen como sigue: enviar(A, mensaje). Enviar un mensaje al buzón A. recibir(A, mensaje). Recibir un mensaje del buzón A.

20 Comunicación Indirecta (cont)
En este esquema, el enlace de comunicación tiene las propiedades siguientes: Se establece un enlace entre un par de procesos sólo si tienen un buzón compartido. Un enlace puede estar asociado a más de dos procesos. Entre cada par de procesos en comunicación puede haber varios enlaces distintos, cada uno de los cuales corresponderá a un buzón. Los enlaces pueden ser unidireccionales o bidireccionales.

21 Comunicación Indirecta (cont)
Supongamos que los procesos Pl, P2 y P3 comparten el buzón A. El proceso Pl envía un mensaje a A, y P2 y P3 ejecutan cada uno un recibir de A. ¿Cuál proceso recibirá el mensaje que Pl envió? Esto puede resolverse de varias maneras: No permitir que un enlace esté asociado a más de dos procesos No permitir que más de un proceso ejecute una operación recibir a la vez Permitir al sistema escoger arbitrariamente cual proceso recibirá el mensaje (P2 0 P3, pero no ambos). El sistema podría identificar el receptor al emisor.

22 Comunicación Indirecta (cont)
Un buzón puede ser propiedad de un proceso o del sistema. En el primer caso (es decir si el buzón está unido a, o definido como parte de, el proceso), se debe distinguir entre el propietario (que sólo puede recibir mensajes a través de este buzón) y el usuario del buzón (que sólo puede enviar mensajes al buzón). Puesto que cada buzón tiene un propietario único, no puede haber confusión respecto a quien debe recibir un mensaje enviado a este buzón Cuando un proceso que posee un buzón termina, el buzón desaparece Cualquier proceso que envíe subsecuentemente un mensaje a ese buzón deberá ser notificado de que el buzón ya no existe, esto se hace por medio del manejo de excepciones

23 Comunicación Indirecta (cont)
Varias formas de designar el dueño y los usuarios de un buzón dado Una posibilidad es permitir que un proceso declare variables de tipo buzón El proceso que declara un buzón es el dueño de ese buzón Cualquier otro proceso que conozca el nombre de dicho buzón podrá usarlo Un buzón propiedad del sistema operativo tiene existencia propia es independiente y no está unido a ningún proceso específico. El sistema operativo establece un mecanismo que permite a un proceso: Crear un buzón nuevo Enviar y recibir mensajes a través del buzón Destruir un buzón

24 Comunicación Indirecta (cont)
El proceso que crea un buzón nuevo es, por omisión, su dueño Inicialmente el dueño es el único proceso que puede recibir mensajes a través de este buzón Sin embargo, la propiedad y el privilegio de recibir se pueden transferir a otros procesos por medio de llamadas al sistema apropiadas Esta posibilidad podría dar lugar a la existencia de múltiples receptores para cada buzón Los procesos también podrían compartir un buzón a través del recurso de creación de procesos.

25 Comunicación Indirecta (cont)
Por ejemplo, si el proceso P crea el buzón A, y luego crea un nuevo proceso Q, P y Q podrían compartir el buzón A Puesto que todos los procesos con derecho de acceso a un buzón podrían terminar en algún momento, podría suceder que después de cierto tiempo un buzón ya no esté accesible a ningún proceso En este caso, el sistema operativo deberá recuperar el espacio utilizado para el buzón. Esta tarea podría requerir alguna forma de recolección de basura en la que ocurre una operación independiente para buscar y liberar memoria que ya no se está usando.

26 Uso de buffers Un enlace tiene cierta capacidad que determina el número de mensajes que pueden residir en él temporalmente Esta propiedad puede visualizarse como una cola de mensajes unida al enlace. Básicamente, hay tres formas de implementar una cola semejante. Capacidad cero (sistema de mensajes sin buffers): La cola tiene como longitud máxima de 0; el enlace no puede tener mensajes esperando en él, el emisor deberá esperar hasta que el destinatario reciba el mensaje. Los dos procesos deben sincronizarse para que pueda haber una transferencia de mensaje. Esta sincronización se denomina encuentro( rendezvous). Capacidad limitada: La cola tiene una longitud finita n; es decir, cuando más n mensajes pueden residir en ella. Si la cola no está llena cuando se envía un mensaje nuevo, éste se coloca en la cola (se copia el mensaje o bien se mantiene un puntero a él) y el emisor puede continuar su ejecución sin esperar. Sin embargo, el enlace tiene una capacidad finita; si está lleno, el emisor deberá esperar hasta que haya espacio libre en la cola. Capacidad ilimitada: La cola tiene una longitud potencialmente infinita; en ella puede esperar cualquier cantidad de mensajes. El emisor nunca espera.

27 Uso de buffers (cont) En los casos de capacidad cero, un proceso no sabe si su mensaje llegó o no a su destino después de llevar a cabo la operación enviar Si esta información es crucial para el cálculo, el emisor deberá comunicarse explícitamente con el receptor para averiguar si este último recibió el mensaje Por ejemplo, supongamos que el proceso P envía un mensaje al proceso Q y sólo puede continuar su ejecución después de haberse recibido el mensaje El proceso P ejecuta la secuencia enviar(Q, mensaje); recibir(Q, mensaje); El proceso Q ejecuta enviar(P, mensaje); recibir(P, "confirmación"); Se dice que tales procesos se comunican asincrónicamente.

28 Casos Especiales El proceso que envía un mensaje nunca espera
Sin embargo, si el receptor no ha recibido el mensaje antes de que el proceso emisor envíe otro mensaje, el primero se perderá La ventaja de este esquema es que no es necesario captar mas de una vez los mensajes grandes La desventaja principal es que la tarea de programación se vuelve más difícil Los procesos necesitan sincronizarse explícitamente para asegurar que no se pierdan los mensajes y también para que el emisor y el receptor no manipulen el buffer de mensajes simultáneamente.

29 Casos Especiales (cont)
El proceso que envía un mensaje espera hasta recibir una respuest Este esquema se adoptó en el sistema operativo Thoth, en el que los mensajes tienen un tamaño fijo (ocho palabras) Un proceso P que envía un mensaje se bloquea hasta que el proceso receptor ha recibido el mensaje y ha devuelto una respuesta de ocho palabras empleando la primitiva reply(P, mensaje) El mensaje de respuesta se escribe sobre el buffer del mensaje original La única diferencia entre las primitivas send y reply es que un send hace que el proceso emisor se bloquee, mientras que reply permite que tanto el proceso emisor como el receptor continúen de inmediato su ejecución Este método de comunicación sincrónico puede expandirse fácilmente para tener un sistema de llamada a procedimientos remotos (RPC, remote procedure call)

30 Casos Especiales (cont)
Los sistemas RPC se basan en la percepción de que una llamada una subrutina o procedimiento en un sistema monoprocesador actúa exactamente como un sistema de mensajes en el que el emisor se bloquea hasta que recibe una respuesta. El mensaje es entonces como una llamada a una subrutina, y el mensaje de retorno contiene el valor de la subrutina calculada El siguiente paso lógico es que procesos concurrentes puedan invocarse mutuamente como subrutinas empleando RPC De hecho, se pueden usar RPC entre procesos que se ejecutan en computadores distintos, con lo cual varios computadores pueden colaborar para beneficio mutuo

31 Condiciones de Excepción
Los sistemas de mensajes son muy útiles en los entornos distribuidos, donde los procesos podrían residir en diferentes sitios (máquinas) En este entorno la probabilidad de que ocurra un error durante la comunicación (y el procesamiento)es mucho mayor que en un entorno de una sola máquina En caso de una sola máquina los mensajes por lo regular se implementan en memoria compartida. Si ocurre una falla todo el sistema falla En un entorno distribuido, los mensajes se transfieren por líneas de comunicación así el fallo de un sitio (o enlace) no causa necesariamente el fallo de todo el sistema Cuando ocurre un fallo en un sistema, sea centralizado o distribuido, el sistema debe intentar recuperarse del error (manejar la condición excepcional)

32 Condiciones de Excepción: El proceso Termina
El emisor o el receptor podría terminar antes de que se procese un mensaje. Esto puede dejar mensajes sin recibir o procesos esperando mensajes que nunca se enviarán. Dos casos: Un proceso receptor P podría esperar un mensaje de un proceso Q que ya terminó. Si no se toman medidas, P se bloqueará eternamente. En este caso, el sistema podría terminar P, o bien notificar a P que Q terminó. El proceso P podría enviar un mensaje a un proceso Q que ya terminó Con el esquema de colocación automática en buffers, no hay problema; P simplemente continuará su ejecución. Si P necesita saber que Q procesó su mensaje, deberá programar explícitamente una confirmación. Si no se usan buffers, P se bloquearía eternamente. Como en el caso 1, el sistema podría terminar P o bien avisarle que Q ya terminó.

33 Condiciones de Excepción: Mensajes Perdidos
Un mensaje del proceso P al proceso Q podría perderse en la red de comunicación a causa de un fallo de hardware o de la línea de comunicaciones Tres métodos El sistema operativo tiene la obligación de detectar este suceso y retransmitir el mensaje. El proceso emisor tiene la obligación de detectar este suceso y retransmitir el mensaje, si desea hacerlo. El sistema operativo tiene la obligación de detectar este suceso; luego avisa al proceso emisor que el mensaje se perdió. El proceso emisor decide qué quiere hacer.

34 Condiciones de Excepción: Mensajes Perdidos (cont)
No siempre es necesario detectar los mensajes perdidos, algunos protocolos de red especifican que los mensajes no son confiables, mientras que otros garantizan la confiabilidad El usuario debe especificar (esto es, notificar al sistema, o bien programar este requisito él mismo) que debe realizarse tal detección El método de detección de perdida de mensaje más común es emplear tiempos límite o plazos Cuando se envía un mensaje, siempre se devuelve un mensaje de respuesta para confirmar la recepción del mensaje El sistema operativo o un proceso puede entonces especificar un intervalo de tiempo durante el cual esperará la llegada del mensaje de acuse de recibo. Si se vence este plazo antes de que llegue la confirmación, el sistema operativo (o el proceso) podrá suponer que el mensaje se perdió y volverá a enviarlo.

35 Condiciones de Excepción: Mensajes Perdidos (cont)
Sin embargo, es posible que no se haya perdido el mensaje, y sólo haya tardado un poco más de lo esperado en viajar por la red. En este caso, podríamos tener múltiples copias del mismo mensaje viajando por la red. Debe haber un mecanismo para distinguir entre los diferentes tipos de mensajes Condiciones de Excepción: Mensajes alterados El mensaje podría llegar a su destino, pero sufrir alteraciones en el camino (por ejemplo, a causa de ruido en el canal de comunicación) Este caso es similar al de un mensaje perdido Por lo regular, el sistema operativo retransmitirá el mensaje original Es común el uso de códigos de verificación de errores (como las sumas de verificación, paridad y CRC) para detectar este tipo de errores.