Comunicacin entre procesos

Comunicacin entre procesos Los sistemas operativos actuales (ao 2008), proveen mecanismos de comunicacin entre procesos. Esta es necesaria en situaciones donde se entregan salidas de procesos como entradas de otros. La razn de ser fundamental de dicha comunicacin es la de evitar que los procesos se estorben mutuamente y lleven al sistema a estados inconsistentes.

Comunicacin entre procesos

Competencia entre procesos Al compartirse recursos, los procesos entran en una dinmica denominada competencia. Dicha competencia se debe al hecho de que los recursos compartidos requieren una asignacin exclusiva al ser modificados por algn proceso. Esquemticamente:
P1

...

P1 i

...

Pn

Comunicacin entre procesos

Secciones crticas Un modo de evitar los conflictos es mediante la exclusin mutua. En los S.O. esto se logra mediante primitivas para solicitar y asignar o denegar los recursos que potencialmente pueden causar conflictos. Se definen secciones crticas, o regiones crticas que el sistema administrar de acuerdo a criterios preestablecidos.

Comunicacin entre procesos

Secciones crticas (continuacin) Dichas regiones crticas deben garantizar que no se produzcan conflictos, pero a la vez tienen que permitir la comparticin de recursos entre procesos. Hay 4 condiciones esenciales para ello:

Exclusividad Flexibilidad con respecto al tiempo de CPU No bloqueo fuera de la regin crtica Atencin garantizada

Comunicacin entre procesos

Secciones crticas (continuacin)

Exclusividad

La regin crtica no estar asignada a ms de un proceso, en ningn momento.

Flexibilidad

Los mecanismos deben ser independientes de las caractersticas de los procesadores en los que funcione el sistema.

Comunicacin entre procesos

Secciones crticas (continuacin)

No bloqueo

No existir bloqueo de un recurso, por parte de los procesos que estn fuera de la regin crtica.
Atencin garantizada

Todo proceso debe tener acceso en algn momento, a una regin crtica que requiera.

Comunicacin entre procesos

Exclusin mutua con espera activa Se examinarn a continuacin algunas soluciones para la exclusin mutua:

Inhabilitacin por Interrupciones Candados Alternancia estricta Solucin de Peterson TSL

Comunicacin entre procesos

Inhabilitacin por Interrupciones Es el mtodo ms simple, consistente en la desactivacin de interrupciones al ingresar un proceso a la regin crtica y su activacin al salir. Esto impide que haya conmutaciones de procesos mientras alguno est en una regin crtica. No es recomendable por varias razones:

Comunicacin entre procesos

Inhabilitacin por Interrupciones

(continuacin)

Un proceso que omita la habilitacin de interrupciones al salir de una regin crtica dejar al sistema inutilizable. Un sistema con ms de una CPU tendra bloqueada la CPU que ejecuta el proceso con acceso a una regin crtica, pero las dems no tendran dicho bloqueo, quedando en la prctica, disponible la r.c. que debera estar bloqueda.

Comunicacin entre procesos

Inhabilitacin por Interrupciones

(continuacin)

Impide al ncleo del sistema la inhabilitacin de interrupciones, por lo que es posible que al entrar un proceso a una regin crtica, lleve al sistema a un estado inconsistente. En la prctica esta solucin es aplicable para bloqueos del ncleo del sistema y muy desaconsejable para el resto de los procesos.

Comunicacin entre procesos

Candados Esta solucin establece una variable de candado (lock) para cada regin crtica. Sus valores son 0 (abierto) o 1 (cerrado), segn la regin crtica est asignada a un proceso o no. Desafortunadamente, es posible por ejemplo, que varios procesos soliciten acceso a una r.c.

Comunicacin entre procesos

Candados (continuacin) El primero registra dnde tomar dicho acceso y antes de verificar esta toma, el sistema conmuta. Antes de volver a CPU el primer proceso, otro solicita, la misma regin crtica y la obtiene. Al volver a conmutarse al primero, ste toma tambin la r.c., que ya estaba asignada al segundo.

Comunicacin entre procesos

Alternancia estricta Consiste en el uso, dentro de los procesos, de instrucciones para leer una variable que les asigna el turno para ingresar a una regin crtica. Esto se denomina espera activa, y es desaconsejable, pues consume tiempo de CPU en una verificacin constante, mientras no es el turno del respectivo proceso. Slo podra utilizarse espera activa si la espera es garantizadamente corta.

Comunicacin entre procesos

Alternancia estricta (continuacin) Al haber un turno signado a algn proceso, ste impide el acceso a la regin crtica respectiva, aunque eventualmente el proceso que lo lleva, no le est utilizando. Esto est en contradiccin con el criterio de no bloqueo fuera de la regin crtica, por lo que esta solucin no es apta para utilizarse en la prctica.

Comunicacin entre procesos

Solucin de Peterson Combinando los conceptos de candados y utilizando variables de advertencia, T. Dekker formul un algoritmo, en que se bas G. Peterson en 1981 para formular una solucin que est ampliamente difundida en la actualidad (ao 2006). Este algoritmo requiere de mecanismos en el hardware que permitan la ejecucin en orden de ciertas instrucciones, para garantizar su funcionamiento.

Comunicacin entre procesos

TSL Existe en el lenguaje de muchas arquitecturas la instruccin TSL (test and set lock), que funciona en un registro especial del procesador, entregando un mecanismo fiable para el uso de variables de candado. De este modo queda establecido un mecanismo para implementar los algoritmos necesarios de acceso a regiones crticas.

Comunicacin entre procesos

TSL (continuacin) Cabe mencionar, que dicho acceso queda garantizado siempre que los procesos liberen adecuadamente las regiones crticas que tienen asignadas. Este problema, derivado de la posibilidad que que un proceso quede indefinidamente con la r.c. tomada, es inherente a la solucin de problemas de exclusin mutua mediante regiones crticas.

Comunicacin entre procesos

Dormir y despertar Las soluciones a los problemas de exclusin mutua con espera activa, estudiadas hasta hora, no slo desperdician tiempo de CPU, sino revisten el riesgo permanente de inversin de prioridades. Este problema consiste en la toma de un recurso por parte de un proceso de baja prioridad, dejando en espera a otro de prioridad mayor.

Comunicacin entre procesos

Dormir y despertar (continuacin) Las soluciones no basadas en espera activa bloquean los procesos al no estar disponible algn recurso requerido, y ms tarde los desbloquean. Esto se lleva a cabo mediante las llamadas SLEEP y WAKEUP, respectivamente.

Comunicacin entre procesos

Problema de productor y consumidor Se supone la existencia de un buffer de tamao limitado. En este buffer el productor agrega elementos y el consumidor los elimina. Mientras haya elementos, el cliente podr eliminar, y mientras no se haya alcanzado el mximo, el productor podr agregar.

Comunicacin entre procesos

Problema de productor y consumidor

(continuacin)

Una solucin con SLEEP y WAKEUP consistira en hacer que los procesos se duerman al no poder actuar sobre el buffer, y sean despertados por el otro, al cambiar las condiciones, para que acte. En condiciones de competencia, sin embargo, cuando ambos acceden a la cuenta de elementos en el buffer, existe el riesgo de que ambos procesos se duerman.

Comunicacin entre procesos

Problema de productor y consumidor

(continuacin)

Esto puede ocurrir mediante la secuencia:

El consumidor encuentra el buffer sin elementos, pero el sistema conmuta de proceso antes de que haga la llamada SLEEP. Posteriormente el productor agrega un elemento y enva la seal WAKEUP al consumidor.

Comunicacin entre procesos

Problema de productor y consumidor

(continuacin)

La seal WAKEUP no tiene efecto, pues el consumidor no ha alcanzado a dormirse.

Al volver el consumidor a CPU se duerme en espera de un WAKEUP que ya fue enviado y se perdi.

El productor sigue llenado el buffer, hasta completarlo y dormirse, en espera de una seal WAKEUP del consumidor.

Comunicacin entre procesos

Problema de productor y consumidor

(continuacin)

Este problema se puede generalizar a n productores y m consumidores. Se ha propuesto el uso de bits de espera, en previsin de esta situacin, de modo que se controle en segunda instancia si las llamadas WAKEUP tuvieron realmente efecto, pero se ven limitados segn el nmero de procesos y el problema de todos modos puede producirse potencialmente.

Comunicacin entre procesos

Semforos En 1965 E. Dijkstra propuso el concepto de semforo. Esto consista en el uso de una variable entera que almacenara la cantidad de seales WAKEUP pendientes. Se asoci a esta variable las acciones:
DOWN: disminucin del valor del semforo en 1 si su valor es mayor que 0. En caso contrario se duerme el proceso sin completar la operacin, y

UP: incremento del valor del semforo.

Comunicacin entre procesos

Semforos (continuacin) Originalmente Dijkstra utiliz respectivamente V y P en lugar de UP y DOWN, incialiales de verhoog [aumentar] y passeer [pasar], probeer [intentar] o pakken [asir] (no hay acuerdo) respectivamente, pero se adoptaron desde 1968 las expresiones ms mnemnicas, usadas actualmente.

Comunicacin entre procesos

Semforos (continuacin) Es importante mencionar que las acciones UP y DOWN definidas por Dijkstra deben ser atmicas, es decir, no constar de varias instrucciones en CPU, para garantizar la funcin de los semforos.

Comunicacin entre procesos

Semforos (continuacin) Es importante mencionar que las acciones UP y DOWN definidas por Dijkstra deben ser atmicas, es decir, no divisibles entre conmutaciones de asignacin de CPU, para garantizar la funcin de los semforos.

Comunicacin entre procesos

Solucin del problema productor / consumidor mediante semforos Mediante semforos se soluciona la prdida de seales WAKEUP. Puesto que UP y DOWN constan de pocas instrucciones, no es crtico para el sistema quedar por esos lapsos con sus interrupciones deshabilitadas.

Comunicacin entre procesos

Solucin del problema productor / consumidor mediante semforos

(continuacin)

Si se trata de un sistema con ms de una CPU, cada semforo se debe proteger con una variable de candado, mediante TSL, de modo que slo una CPU tenga acceso a cada semforo. A diferencia de la solucin anterior, en sta no se malgasta tiempo de CPU en esperas activas.

Comunicacin entre procesos

Solucin del problema productor / consumidor mediante semforos

(continuacin)

Se utilizan tres semforos:

full: Cuenta de posiciones ocupadas en el buffer. Comienza con valor 0. empty: Cuenta de posiciones disponibles en el buffer. Comienza con valor N (nmero de posiciones disponibles). mutex: para definir una regin crtica. Comienza con valor 1.

Comunicacin entre procesos

Solucin del problema productor / consumidor mediante semforos

(continuacin)

El semforo mutex se utiliza para garantizar exclusin mutua y consiste en un semforo binario (de 2 estados). Los otros se encargan de la sincronizacin. En este caso, de la definicin de secuencias vlidas o no.

Comunicacin entre procesos

Solucin del problema productor / consumidor mediante semforos

(continuacin)

Esta solucin encierra potencialmete un problema denominado bloqueo mutuo. Al invertise el orden de las seales DOWN sobre mutex y empty, o mutex y full, respetivamente el productor o el consumidor pueden quedar con la regin crtica tomada. El otro proceso esperar que el primero la libere, y el primero no estar habilitado para actuar, mientras no intervanga el segundo.

Comunicacin entre procesos

Monitores Originalmente se propuso una primitiva de sincronizacin de nivel ms alto, en los aos '70 (Hoare, 1974 y Brinch Hansen 1975). Esta primitiva, denominada monitor, inclua procedimientos, variables y estructuras de datos. Estos dejan sus procedimientos disponibles para los procesos, pero no sus estructuras de datos internas.

Comunicacin entre procesos

Monitores (continuacin) El acceso a un monitor por parte de los procesos es exclusivo. Al invocar un proceso, un procedimiento de monitor, verifica que no haya acceso a dicho monitor desde otro proceso. Si no encuentra otro proceso que utiliza procedimientos del monitor contina, de lo contrario, suspende su acceso.

Comunicacin entre procesos

Monitores (continuacin) Este tipo de acceso, es tarea del respectivo compilador en que cada proceso es creado. Esto permite a los programadores utilizar los recursos con regiones crticas de manera transparente. Si bien este bloqueo de los procesos al no poder utilizar un monitor queda resuelto con en compilador, existe otro tipo de bloqueo, dado por las variables de condicin.

Comunicacin entre procesos

Monitores (continuacin) Las operaciones para acceder a las variables de condicin dentro de un monitor son WAIT y SIGNAL. Al ejecutarse WAIT sobre una variable de condicin, el proceso invocador se bloquea y queda disponible el monitor para otros procesos.

Comunicacin entre procesos

Monitores (continuacin) Para desbloquear (despertar) proceso bloqueado, un segundo proceso puede enviar SIGNAL sobre la variable de condicin que bloque al primer proceso. Esto obliga a definir reglas para definir qu acciones tomar tras ejecutarse SIGNAL. Hoare propuso conmutar al proceso recin desbloqueado.

Comunicacin entre procesos

Monitores (continuacin)
Brinch Hansen, el uso de SIGNAL slo como ltima instruccin en un procedimiento de monitor, esto es, tras invocar SIGNAL, un proceso hace abandono de un monitor. Es ms fcil de implementar esta ltima modalidad, al no involucrar conmutaciones de procesos. La diferencia crucial de WAIT y SIGNAL con SLEEP y WAKEUP es la existencia del monitor, que garantiza una sincronizacin adecuada.

Comunicacin entre procesos

Monitores (continuacin)
Si bien los monitores resuelven problemas de concurrencia de manera ms fiable que los semforos, la mayora de los lenguajes de programacin carecen de ellos. Se podra conclur que los semforos son de muy nivel bajo y los monitores, muy alto, para solucionar los problemas de excusin mutua. Adems, estn concebidos para sistemas con mltiples CPUs, y memoria compartida. No funcionan en sistemas distribuidos, con procesos repartidos en distintas memorias.

Comunicacin entre procesos

Transferencia de mensajes Se basa en las llamadas (tambin denominadas primitivas): SEND: send(destino, &mensaje) Enva un mensaje a algn destino determinado, y

RECEIVE: receive(origen, &mensaje) Recibe un mensaje desde un origen determinado.

Si no hay mensaje disponible, el receptor puede bloquearse en espera de uno, o devolver un cdigo de error.

Comunicacin entre procesos

Problemas en el diseo de sistemas con transferencia de mensajes

(continuacin)

La transferencia de mensajes fue concebida para sistemas distribuidos. Por la naturaleza fsica de tales sistemas, surgen problemas de distinta naturaleza, particularmente la prdida de mensajes. Para subsanarlos, se ha definido el conceptos de acuso de recibo o confirmacin.

Comunicacin entre procesos

Problemas en el diseo de sistemas con transferencia de mensajes

(continuacin)

En ausencia del mismo, tras un plazo a definir, se puede programar una retransmisin. Es posible tambin, una prdida de dichos acusos de recibo. Para subsanar un envo repetido de mensajes, es necesaria una identificacin de los mismos.

Comunicacin entre procesos

Problemas en el diseo de sistemas con transferencia de mensajes

(continuacin)

Otro problema en sistemas distribuidos es el de verificacin de autenticidad, que garantice a los procesos que se comunican, que su interlocutor es el esperado, y evite suplantaciones. Cabe destacar que las soluciones basadas en transferencia de mensajes son considerablemente ms comlejas que las basadas en semforos o monitores.

Comunicacin entre procesos

Solucin del problema productor / consumidor con transferencia de mensajes Se puede establecer N mensajes, uno por cada espacio en el buffer. Cada vez que el productor o el consumidor modifican el buffer, envan un mensaje al otro proceso. Los mensajes pueden ir directamente a las direcciones de memoria que alojan los procesos, o bien a una estructura de datos especial, denominada buzn.

Comunicacin entre procesos

Solucin del problema productor / consumidor con transferencia de mensajes (continuacin) En general, pueden surgir problemas al ser limitado el espacio asignado a los buzones, en este ejemplo es fijo. Otra modalidad posible, es sin buzones, bloqueando los procesos que han ejecutado SEND, hasta que se verifica el respectivo RECEIVE.

Comunicacin entre procesos

Solucin del problema productor / consumidor con transferencia de mensajes (continuacin) Este esquema, de sincronizacin estricta, se denomina cita o rendezvous. Los conductos, tuberas o pipes de Unix, corresponden a buzones. En general no existe verificacin de tamaos.