Concurrencia: exclusin mutua y sincronizacin

INTRODUCCIN
Los temas fundamentales del diseo de sistemas operativos estn relacionados con la gestin de procesos e hilos: Multiprogramacin: consiste en la gestin de varios procesos dentro de un sistema monoprocesador. Multiprocesamiento: consiste en la gestin de varios procesos, dentro de un sistema multiprocesador. Procesamiento distribuido: consiste en la gestin de varios procesos, ejecutndose en sistemas de computadores mltiples y distribuidos. La reciente proliferacin de las agrupaciones es el principal ejemplo de este tipo de sistemas. La concurrencia es fundamental en todas estas reas y para el diseo sistemas operativos. La concurrencia comprende un gran nmero de cuestiones de diseo, incluida la comunicacin entre procesos, comparticin y competencia por los recursos, sincronizacin de la ejecucin de varios procesos y asignacin del tiempo de procesador a los procesos. Se ver que estas cuestiones no solo surgen en entornos de multiprocesadores y proceso distribuido, sino incluso en sistemas multiprogramados con un solo procesador. La concurrencia puede presentarse en tres contextos diferentes: Mltiples aplicaciones: la multiprogramacin se cre para permitir que el tiempo de procesador de la mquina fuese compartido dinmicamente entre varias aplicaciones activas. Aplicaciones estructuradas: como ampliacin de los principios del diseo modular y la programacin estructurada, algunas aplicaciones pueden implementarse eficazmente como un conjunto de procesos concurrentes. Estructura del sistema operativo: las mismas ventajas de estructuracin son aplicables a los programadores de sistemas y se ha comprobado que algunos sistemas operativos estn implementados como un conjunto de procesos o hilos.

PRINCIPIOS GENERALES DE LA CONCURRENCIA En un sistema multiprogramado con un nico procesador, los procesos se intercalan en el tiempo aparentando una ejecucin simultnea. Aunque no se logra un procesamiento paralelo y produce una sobrecarga en los intercambios de procesos, la ejecucin intercalada produce beneficios en la eficiencia del procesamiento y en la estructuracin de los programas. La intercalacin y la superposicin pueden contemplarse como ejemplos de procesamiento concurrente en un sistema monoprocesador, los problemas son consecuencia de la velocidad de ejecucin de los procesos que no pueden predecirse y depende de las actividades de otros procesos, de la forma en que el sistema operativo trata las interrupciones surgen las siguientes dificultades: 1. Compartir recursos globales es riesgoso 2. Para el sistema operativo es difcil gestionar la asignacin ptima de recursos. Las dificultades anteriores tambin se presentan en los sistemas multiprocesador. El hecho de compartir recursos ocasiona problemas, por esto es necesario proteger a dichos recursos.
Los problemas de concurrencia se producen incluso cuando hay un nico procesado

LABORES DEL SISTEMA OPERATIVO Elementos de gestin y diseo que surgen por causa de la concurrencia: 1) El sistema operativo debe seguir a los distintos procesos activos 2) El sistema operativo debe asignar y retirar los distintos recursos a cada proceso activo, entre estos se incluyen: _Tiempo de procesador _Memoria _Archivos _Dispositivos de E/S 3) El sistema operativo debe proteger los datos y los recursos fsicos de cada proceso contra injerencias no intencionadas de otros procesos. 4) Los resultados de un proceso deben ser independientes de la velocidad a la que se realiza la ejecucin de otros procesos concurrentes.

Para abordar la independencia de la velocidad debemos ver las formas en las que los procesos interactan. INTERACCIN ENTRE PROCESOS Se puede clasificar los en que interactan los procesos en funcin del nivel de conocimiento que cada proceso tiene de la existencia de los dems. Existen tres niveles de conocimiento: 1) Los procesos no tienen conocimiento de los dems: son procesos independientes que no operan juntos. Ej: la multiprogramacin de procesos independientes. Aunque los procesos no trabajen juntos, el sistema operativo se encarga de la "competencia" por los recursos. 2) Los procesos tienen un conocimiento indirecto de los otros: los procesos no conocen a los otros por sus identificadores de proceso, pero muestran cooperacin el objeto comn. 3) Los procesos tienen conocimiento directo de los otros: los procesos se comunican por el identificador de proceso y pueden trabajar conjuntamente. Competencia entre procesos por los recursos Los procesos concurrentes entran en conflicto cuando compiten por el uso del mismo recurso; dos o ms procesos necesitan acceder a un recurso durante su ejecucin .Cada proceso debe dejar tal y como est el estado del recurso que utilice. La ejecucin de un proceso puede influir en el comportamiento de los procesos que compiten. Por Ej. Si dos procesos desean acceder a un recurso, el sistema operativo le asignar el recurso a uno y el otro tendr que esperar. Cuando hay procesos en competencia, se deben solucionar tres problemas de control: la necesidad de exclusin mutua. Suponiendo que dos procesos quieren acceder a un recurso no compartible. A estos recursos se les llama "recursos crticos" y la parte del programa que los utiliza es la "seccin crtica del programa. Es importante que slo un programa pueda acceder a su seccin crtica en un momento dado. Hacer que se cumpla la exclusin mutua provoca un interbloqueo. Otro problema es la inanicin si tres procesos necesitan acceder a un recurso, P1 posee al recurso, luego lo abandona y le concede el acceso al siguiente proceso P2, P1 solicita acceso de nuevo y el sistema operativo concede el acceso a P1 YP2 alternativamente, se puede negar indefinidamente a P3 el acceso al recurso. El control de competencia involucra al sistema operativo, porque es el que asigna los recursos.

Cooperacin entre procesos por compartimiento

Comprende los procesos que interactan con otros sin tener conocimiento explcito de ellos. Ej. : Varios procesos pueden tener acceso a variables compartidas.

Los procesos deben cooperar para asegurar que los datos que se comparten se gestionan correctamente. Los mecanismos de control deben garantizar la integridad de los datos compartidos.

Cooperacin entre procesos por comunicacin

Los distintos procesos participan en una labor comn que une a todos los procesos. La comunicacin sincroniza o coordina las distintas actividades, est formada por mensajes de algn tipo. Las primitivas para enviar y recibir mensajes, vienen dadas como parte del lenguaje de programacin o por el ncleo del sistema operativo REQUISITOS PARA LA EXCLUSIN MUTUA 1. Slo un proceso, de todos los que poseen secciones crticas por el mismo recurso compartido, debe tener permiso para entrar en ella en un momento dado. 2. Un proceso que se interrumpe en una seccin no crtica debe hacerlo sin interferir con los otros procesos. 3. Un proceso no debe poder solicitar acceso a una seccin crtica para despus ser demorado indefinidamente, no puede permitirse el interbloqueo o la inanicin. 4. Si ningn proceso est en su seccin crtica, cualquier proceso que solicite entrar en la suya debe poder hacerlo sin demora. 5. No se debe suponer sobre la velocidad relativa de los procesos o el nmero de procesadores. 6. Un proceso permanece en su seccin crtica por un tiempo finito. Una manera de satisfacer los requisitos de exclusin mutua es dejar la responsabilidad a los procesos que deseen ejecutar concurrentemente. Tanto si son programas del sistema como de aplicacin, los procesos deben coordinarse unos con otros para cumplir la exclusin mutua, sin ayuda del lenguaje de programacin o del sistema operativo. Estos mtodos se conocen como soluciones por software.

EXCLUSIN MUTUA: SOLUCIONES POR SOFTWARE Pueden implementarse soluciones de software para los procesos concurrentes que se ejecuten en mquinas monoprocesador o multiprocesador con memoria principal compartida. ALGORITMO DE DEKKER La solucin se desarrolla por etapas. Este mtodo ilustra la mayora de los errores habituales que se producen en la construccin de programas concurrentes.

Primer intento Cualquier intento de exclusin mutua debe depender de algunos mecanismos bsicos de exclusin en el hardware. El ms habitual es que slo se puede acceder a una posicin de memoria en cada instante, teniendo en cuenta esto se reserva una posicin de memoria global llamada turno. Un proceso que desea ejecutar su seccin crtica primero evala el contenido de turno. Si el valor de turno es igual al nmero del proceso, el proceso puede continuar con su seccin crtica. En otro caso el proceso debe esperar. El proceso en espera, lee repetitivamente el valor de turno hasta que puede entrar en su seccin crtica. Este procedimiento se llama espera activa. Despus de que un proceso accede a su seccin crtica y termina con ella, debe actualizar el valor de turno para el otro proceso. Segundo intento: Cada proceso debe tener su propia llave de la seccin crtica para que, si uno de ellos falla, pueda seguir accediendo a su seccin crtica; para esto se define un vector booleano seal. Cada proceso puede evaluar el valor de seal del otro, pero no modificarlo. Cuando un proceso desea entrar en su seccin crtica, comprueba la variable seal del otro hasta que tiene el valor falso (indica que el otro proceso no est en su seccin crtica). Asigna a su propia seal el valor cierto y entra en su seccin crtica. Cuando deja su seccin crtica asigna falso a su seal. Si uno de los procesos falla fuera de la seccin crtica, incluso el cdigo para dar valor a las variables seal, el otro proceso no se queda bloqueado. El otro proceso puede entrar en su seccin crtica tantas veces como quiera, porque la variable seal del otro proceso est siempre en falso. Pero si un proceso falla en su seccin crtica o despus de haber asignado cierto a su seal, el otro proceso estar bloqueado permanentemente. Tercer intento El segundo intento falla porque un proceso puede cambiar su estado despus de que el otro proceso lo ha comprobado pero antes de que pueda entrar en su seccin crtica. Si un proceso falla dentro de su seccin crtica, incluso el cdigo que da valor a la variable seal que controla el acceso a la seccin crtica, el otro proceso se bloquea y si un proceso falla fuera de su seccin crtica, el otro proceso no se bloquea. Si ambos procesos ponen sus variables seal a cierto antes de que ambos hayan ejecutado una sentencia, cada uno pensar que el otro ha entrado en su seccin crtica, generando as un interbloqueo. Cuarto intento

En el tercer intento, un proceso fijaba su estado sin conocer el estado del otro. Se puede arreglar esto haciendo que los procesos activen su seal para indicar que desean entrar en la seccin crtica pero deben estar listos para desactivar la variable seal y ceder la preferencia al otro proceso. Existe una situacin llamada bloqueo vital, esto no es un interbloqueo, porque cualquier cambio en la velocidad relativa de los procesos rompera este ciclo y permitira a uno entrar en la seccin crtica. Recordando que el interbloqueo se produce cuando un conjunto de procesos desean entrar en sus secciones crticas, pero ninguno lo consigue. Con el bloqueo vital hay posibles secuencias de ejecucin con xito. Una solucin correcta Hay que observar el estado de ambos procesos, que est dado por la variable seal, pero es necesario imponer orden en la actividad de los procesos para evitar el problema de "cortesa mutua". La variable turno del primer intento puede usarse en esta labor, indicando que proceso tiene prioridad para exigir la entrada a su seccin crtica. ALGORITMO DE PETERSON El algoritmo de Deker resuelve el problema de la exclusin mutua pero mediante un programa complejo, difcil de seguir y cuya correccin es difcil de demostrar. Peterson ha desarrollado una solucin simple y elegante. Como antes, la variable global seal indica la posicin de cada proceso con respecto a la exclusin mutua y la variable global turno resuelve los conflictos de simultaneidad. Considrese el proceso P0. Una vez que ha puesto seal[0] a cierto, P1 no puede entrar en su seccin crtica. Si P1 esta aun en su seccin crtica, entonces seal[1] = cierto y P0 est bloqueado en su bucle while. Esto significa que seal[1] es cierto y turno = 1. P0 puede entrar en su seccin crtica cuando seal[1] se ponga a falso o cuando turno se ponga a 0. Considrense ahora los siguientes casos exhaustivos: 1. P1 no est interesado en entrar en su seccin crtica. Este caso es imposible porque implica que seal[1] = falso. 2. P1 est esperando entrar en su seccin crtica. Este caso es tambin imposible porque si turno = 1, P1 podra entrar en su seccin crtica. 3. P1 entra en su seccin crtica varias veces y monopoliza el acceso a ella. Esto no puede pasar porque P1 est obligado a dar a P0 una oportunidad poniendo turno a 0 antes de cada intento de entrar en su seccin crtica. As pues, se tiene una solucin posible al problema de la exclusin mutua para dos procesos. Es ms, el algoritmo de Peterson se puede generalizar fcilmente al caso de n procesos. Disciplina de cola

La disciplina de cola mas simple es la de primero en llegar/ primero en salir, pero sta puede no ser suficiente si algunos mensajes son mas urgentes que otros. Una alternativa es permitir la especificacin de prioridades de los mensajes, en funcin del tipo de mensaje o por designacin del emisor. Otra alternativa es permitir al receptor examinar la cola de mensajes y seleccionar el mensaje a recibir a continuacin.

Exclusin mutua Supngase que se usan primitivas receive bloqueantes y send no bloqueantes. Un conjunto de procesos concurrentes comparten un buzn, exmut, que puede ser usado por todos los procesos para enviar y recibir. El buzn contiene inicialmente un nico mensaje, de contenido nulo. Un proceso que desea entrar en su seccin crtica intenta primero recibir el mensaje. Si el buzn est vaco, el proceso se bloquea. Una vez que un proceso ha conseguido el mensaje, ejecuta su seccin crtica y, despus, devuelve el mensaje al buzn. De este modo, el mensaje funciona como testigo que se pasa de un proceso a otro. Esta tcnica supone que si hay ms de un proceso ejecutando la accin receive concurrentemente, entonces:

Si hay un mensaje, se entrega slo a uno de los procesos y los otros se bloquean. Si el buzn est vaco, todos los procesos se bloquean; cuando haya un mensaje disponible, slo se activar y tomar el mensaje uno de los procesos bloqueados.

EXCLUSIN MUTUA: SOLUCIONES POR HARDWARE INHABILITACIN DE INTERRUPCIONES En una mquina monoprocesador, la ejecucin de procesos concurrentes no puede superponerse; los procesos solo pueden intercalarse. Es ms, un proceso continuar ejecutndose hasta que solicite un servicio el sistema operativo o hasta que sea interrumpido. Por lo tanto, para garantizar la exclusin mutua, es suficiente con impedir que un proceso sea interrumpido. Esta capacidad puede ofrecerse en forma de primitivas definidas por el ncleo del sistema para habilitar o inhabilitar las interrupciones. Un proceso puede hacer cumplir la exclusin mutua del siguiente modo:
While (cierto) { /*inhabilitar interrupciones */; /* seccin critica */;

/* habilitar interrupciones */; /* resto */; }

Puesto que la seccin crtica no puede ser interrumpida, la exclusin mutua est garantizada. Sin embargo, el precio de esta solucin es alto. La eficiencia de la ejecucin puede verse notablemente degradada debido a que se limita la capacidad del procesador para intercalar programas. Un segundo problema es que est tcnica no funciona en arquitecturas de multiprocesador. Cuando el sistema tenga ms de un procesador, es posible (y habitual) que haya ms de un proceso ejecutndose al mismo tiempo. En este caso, inhabilitar las interrupciones no garantiza la exclusin mutua. INSTRUCCIONES ESPECIALES DE MAQUINA En configuraciones multiprocesador, varios procesadores comparten el acceso a una memoria principal comn. En este caso, no hay relacin maestro/esclavo, sino que los procesadores funcionan independientemente en una relacin de igualdad. No hay un mecanismo de interrupciones entre los procesadores en el que se pueda basar la exclusin mutua. A nivel de hardware, como se ha mencionado, los accesos a posiciones de memoria excluyen cualquier otro acceso a la misma posicin. Con esta base, los diseadores han propuesto varias instrucciones de mquina que realizan dos acciones atmicamente, tales cono leer y escribir o leer y examinar, sobre una misma posicin de memoria en un nico ciclo de lectura de instruccin. Puesto que estas acciones se realizan en un nico ciclo de instruccin, no estn sujetas a injerencias por parte de otras instrucciones. -La instruccin COMPARAR Y FIJAR (TS, Test and Set)puede definirse de la siguiente forma:
booleano TS(int i) { if (I==0) { I=1; return cierto; } else

{ return falso; } }

La instruccin examina el valor de su argumento i. Si el valor es 0 , lo cambia por 1 y devuelve cierto. En otro caso, el valor no se modifica y se devuelve falso. La funcin Comparar y Fijar se ejecuta atmicamente en su totalidad, es decir, no esta sujeta a interrupciones. La instruccin INTERCAMBIAR se puede definir como sigue:
void intercambiar (int registro, int memoria) { int temp; temp = memoria; memoria = registro; registro = temp; }

Esta instruccin intercambia el contenido de un registro con el de una posicin de memoria. Durante la ejecucin de la instruccin, se bloquea el acceso a la posicin de memoria de cualquier otra instruccin que haga referencia a la misma posicin. Propiedades de las soluciones con instrucciones de maquina El uso de instrucciones especiales de la maquina para hacer cumplir la exclusin mutua tiene varias ventajas:

Es aplicable a cualquier nmero de procesos en sistemas con memoria compartida, tanto de monoprocesador como de multiprocesador. Es simple y fcil de verificar. Puede usarse para disponer de varias secciones crticas; cada seccin crtica puede definirse con su propia variable.

Algunas desventajas importantes son las siguientes:

SE EMPLEA ESPERA ACTIVA. As pues, mientras un proceso est esperando para acceder a la seccin crtica, contina consumiendo tiempo del procesador.

PUEDE PRODUCIRSE INANICIN. Cuando un proceso abandona la seccin crtica y hay ms de un proceso esperando, la seleccin es arbitraria. As pues se podra denegar el acceso a algn proceso indefinidamente. PUEDE PRODUCIRSE INTERBLOQUEO. Supngase la siguiente escena en un sistema monoprocesador. El proceso "P1" ejecuta una instruccin especial (sea TS o Intercambiar) y entra su seccin crtica. Se interrumpe a "P1" para dar el procesador a "P2", que tiene mayor prioridad. Si "P2" intenta ahora usar el mismo recurso que "P1", se le negar el acceso por el mecanismo de exclusin mutua. De este modo, "P2" entrar en un bucle de espera activa. Sin embargo, "P1" nunca ser expedido porque su prioridad es menor que la del proceso listo "p2".

SEMFOROS Para solucionar problemas de procesos concurentes, se diseo un S.O. como un conjunto de procesos secuenciales, eficiente y fiables para dar soporte a la cooperacin. Los procesos de usuario podran utilizar estos mecanismos si el procesador y el S.O. los hacan disponible. El principio fundamental es el siguiente, 20+ procesos pueden cooperar por medio de simples seales, de manera que se pueda obligar a un proceso a detener en una posicin determinada hasta que reciba una seal especfica. Para la sealizacin se usan variables especiales llamadas semforos "S", los procesos ejecutan las primitivas wait(s) si la seal aun no se transmiti, el proceso se suspende hasta que tiene lugar la transmisin. A los semforos se los contemplan como variables que tienen un N entero sobre el que se definen las siguientes operaciones: a. un semforo puede iniciarse con un valor negativo b. la operacin wait disminuye el valor del semforo. Si el valor no es positivo el proceso que ejecuta wait se bloquea. c. las operaciones signal incrementa el N del semforo. Si el valor es positivo se desbloquea el proceso bloqueado por una operacin wait. No hay forma de examinar o manipular los semforos aparte de estas tres operaciones. Las primitivas wait y signal se suponen atmicas, es decir no pueden ser interrumpidas y cada rutina puede considerarse como un peso indivisible. Un semforo solo puede tomar los valores 0 y 1. Son ms sencillos de implantar y pueden demostrarse que tienen la misma potencia de expresin que los semforos generales. En ambos semforos se emplean una cola para mantener los procesos en espera, la cuestin reside en el orden en que se retiran los procesos de la cola. La poltica utilizada el la de FIFO; el proceso que estuvo bloqueado durante mas tiempo se libera de la cola, se

denomina semforo robusto (incluye esta estrategia). Un semforo dbil no especifica el orden en que se retiran los procesos de la cola. Los semforos robustos garantizan la inexistencia de inanicin en el algoritmo de exclusin mutua, pero no as en los semforos dbiles, se supone que los semforos son siempre robustos ya que son los ms adecuados y porque son los tipos de semforos que ms incluyen los S.O. Implementacin de los semforos. Como se menciono anteriormente es impredecible que las operaciones wait y signal sean implementadas como primitivas atmicas. La esencia del problema del productor/consumidor, es la exclusion mutua: solo 1 proceso puede manipular un semforo a la vez, en una operacin wait o signal. Se pueden utilizar cualquier esquema de software con los algoritmos de Dekker o Peterson los que suponen una sobrecarga de procesos sustancial. Otra alternativa es usar uno de los esquemas de soporte del hardware p/la exclusion mutua.. En sistemas monoprocesador procesador, se pueden inhibir las interrupciones durante una operacin wait o signal.

MONITORES

Los monitores son estructuras de un lenguaje de programacin que ofrecen una funcionalidad equivalente a las de los semforos pero son ms fciles de controlar. El concepto de monitor fue definido por primera vez en [HOAR 74] . La estructura de monitor se ha implementado en varios lenguajes de programacin como: Pascal concurrente, Modulo-2, Java, etc. En concreto, para una lista enlazada se puede necesitar un cierre que bloquee todas las listas enlazadas o bien un cierre por cada elemento de una lista. Monitores con Seales: ( definicin de Hoare ) Un monitor es un modulo de software que consta de uno o ms procedimientos, una secuencia de inicio y uno datos locales. Sus caractersticas son las siguientes: 1. Solo los procedimientos del monitor acceden a variables de datos locales. 2. Un proceso entra en el monitor invocando a uno de sus procedimientos. 3. En el monitor solo un proceso puede ser ejecutado en un momento dado; cualquier otro proceso quedara suspendido esperando la disponibilidad del monitor. Al ser un proceso por vez, el monitor puede ofrecer un servicio de exclusin mutua fcilmente. As una estructura de datos puede protegerse situndola dentro de un monitor.

Los monitores deben ofrecer herramientas de sincronizacin. Por ejemplo: si un proceso llama a un monitor y una vez dentro de l el proceso queda suspendido esperando alguna condicin, har falta un servicio que libere al monitor y lo deje disponible para el siguiente proceso. Mas tarde cuando la condicin se cumpla el proceso suspendido podr regresar al monitor y ejecutarse desde el momento de la suspensin. El monitor proporciona variables de condicin que son accesibles solo desde dentro del monitor. Hay dos funciones para operar variables de condicin:

cwait (c): suspende la ejecucin del proceso que llama bajo la condicin "c". El monitor est ahora disponible para otro proceso. csignal (c): retorna la ejecucin de un proceso suspendido despus de un cwait, bajo la misma condicin. Si hay varios procesos elige uno de ellos.

Si un proceso de monitor ejecuta un csignal y no hay tareas esperando entonces el csignal de pierde. Aunque un proceso puede entrar al monitor llamando a cualquiera de sus procedimientos, se puede decir que el monitor tiene un solo punto de acceso, custodiado para que solo un proceso este en el monitor en un instante dado. Si existen otros procesos tratando de entrar al monitor, estos se colocan en una cola de procesos suspendidos esperando la disponibilidad del monitor. Un proceso dentro de un monitor puede suspenderse a s mismo, temporalmente, bajo la condicin X ejecutando cwait(x), entonces se coloca en una cola de procesos que esperan que cambie la condicin X entonces ejecuta un csignal(x) que avisa a la cola de condicin correspondiente de que la condicin a cambiado. En el cdigo se puede apreciar la solucin al problema de productor / consumidor usando monitores: El modulo monitor, buffers_acotado, controla el buffer para almacenar y retirar caracteres. El monitor incluye dos variables de condicin: No-lleno es verdadero su hay lugar para agregar al menos un carcter. No-vaci es verdadero si hay al menos un carcter en el buffer. Un productor solo puede agregar caracteres al buffer mediante el procedimiento aadir del monitor; el productor no tiene acceso directo al buffer. El procedimiento comprueba si hay espacio en el buffer, mediante la condicin no-lleno, si no lo hay el proceso queda suspendido y cualquier otro proceso (consumidor o productor) puede entrar al monitor. Luego, cuando el buffer ya no esta lleno, el proceso se retira de la cola y es reactivado. Luego de aadir un carcter el proceso activa la condicin no-vaci.

La estructura misma del monitor garantiza la exclusin mutua (solo un proceso por vez puede acceder al buffer). Sin embargo, el programador debe situar correctamente las primitivas cwait( ) y csignal( ) en el monitor para evitar que los procesos depositen elementos en un buffer lleno o los extraigan de uno vaci. Un proceso sale del monitor inmediatamente despus de ejecutar csignal( ). Si csignal( ) se ejecuta antes del final entonces ese proceso libera el monitor y esta colocado en una lista de procesos suspendidos. Un nuevo proceso puede entrar el monitor. Si no hay procesos esperando en la condicin X, la ejecucin de csignal (x) no tiene efecto. Es posible cometer errores en la sincronizacin de los monitores, por ejemplo, si se omite cualquiera de las funciones csignal() en el monitor buffer _ acotado los procesos que entran en la cola de condicin permanecen colgados permanentemente. Sin embargo la ventaja de los monitores es que todas las funciones de sincronizacin estn incluidas dentro del monitor, lo que permite una fcil deteccin y correccin de fallas de sincronizacin. Monitores con Notificacin y Difusin (definicin de Lampson y Redell) Son varios los inconvenientes que presenta la solucin de Hoare: -Si el proceso que ejecuta el csignal( ) no ha terminado en el monitor, se necesitaran dos cambios de procesos adicionales: uno para suspender el proceso y otro para reanudarlo. -La planificacin de procesos asociados con las seales debe ser muy fiable. Si un proceso ejecuta un csignal ( ), el proceso de la cola de condicin correspondiente debe activarse de inmediato, antes de que ingrese otro proceso del exterior o cambie la condicin bajo la que se activ el proceso. Otro caso seria que un proceso productor escribe un carcter en el buffer y falla antes de dar la seal, entonces la cola de condicin no-vaca se colgara para siempre. Lampson y Redell desarrollaron una definicin de monitores para el lenguaje MESA [Lamp 80]. La estructura de mesa reemplaza la primitiva csignal( ) por cnotify( ). Cuando un proceso ejecuta cnotify(x) enva una notificacin a la cola de condicin X, lo cual no significa que el proceso que esta ocupando el monitor vaya a detenerse, simplemente el cnotify(x) avisa al proceso de la cola de condicin correspondiente de que ser reanudado en un futuro cercano. Puesto que esta no garantiza que un proceso exterior entre al monitor, el proceso debe comprobar la condicin nuevamente. En el cdigo, la sentencia IF se reemplaza por un bucle While, lo cual genera una evaluacin extra de la variable, pero sin embargo no hay cambios de procesos extra. Una modificacin til seria asociar un temporizador de guardia a cnotify( ) que permitira que un proceso que ha esperado durante el intervalo mximo sea situado en estado de listo, independientemente de s se ha notificado la condicin.

Con la norma de notificar a los procesos en lugar de reactivarlos, es posible aadir una primitiva de difusin cbroadcast. La difusin provoca que todos los procesos que estn esperando por una condicin se coloquen en el estado de listo. Esto es til cuando un proceso no sabe cuantos procesos deben reactivarse. El mtodo Lampson/Redell es menos propenso a errores debido a que cada procedimiento comprueba la condicin luego de ser despertado, por medio de la instruccin while, un proceso puede realizar una seal o una difusin incorrectamente sin provocar un error en el programa que la recibe. Adems este modelo presta un mtodo mas modular de construccin de programas. Hay dos niveles de condicin que deben satisfacerse para los procesos secuenciales cooperantes. 1. Estructura de datos consistentes: significa que el monitor hace cumplir la exclusin mutua y concluye la operacin de entrada o salida antes de permitir cualquier otra operacin sobre el buffer. 2. La misma condicin del nivel 1 y, adems disponer de suficiente memoria para que este proceso pueda completar su solicitud de asignacin. PASO DE MENSAJES Son 2 los requisitos bsicos que deben satisfacerse cuando los procesos interactan entre si. Ellos son:

La sincronizacin La comunicacin

Los procesos tienen que sincronizarse para cumplir la exclusin mutua, los procesos cooperantes pueden necesitar intercambiar informacin. El paso de mensajes es un mtodo que permite que se realice ambas funciones. Este mtodo tiene la ventaja de que es de fcil implementacin en sistemas distribuidos y tambin es sistemas de multiprocesador y monoprocesador de memoria compartida. La funcionalidad real del paso de mensajes, generalmente, se da por medio de un par de primitivas:
send(destino, mensaje) receive(origen, mensaje)

Este es el conjunto mnimo de operaciones necesarias para que los procesos puedan dedicarse al paso de mensajes.

SINCRONIZACION La comunicacin de un mensaje entre 2 procesos implica cierto nivel de sincronizacin entre ambos. El receptor no puede recibir un mensaje hasta que sea enviado por otro proceso. Adems hace falta especificar que le sucede a un proceso despus de ejecutar una primitiva SEND o RECEIVE. Considrese en primer lugar la primitiva send. Cuando se ejecuta una primitiva send en un proceso, hay 2 posibilidades: o bien el proceso emisor se bloquea hasta que recibe el mensaje o no se bloquea. Igualmente cuando un proceso ejecuta una primitiva RECEIVE, existen 2 opciones: 1) Si previamente se ha enviado algn mensaje, este es recibido y continua la ejecucin. 2) Si no hay ningn mensaje esperando entonces: a) el proceso se bloquea hasta que llega un mensaje o, b) el proceso contina ejecutando, abandonando el intento de recepcin. El emisor y el receptor pueden ser bloqueantes o no bloqueantes. Existen 3 tipos de combinaciones pero un sistema solo implementa uno o dos. I) Envo bloqueante, recepcin bloqueante: tanto el emisor como el receptor se bloquean hasta que llega el mensaje; esta tcnica se conoce como rendezvous. II) Envo no bloqueante, recepcin bloqueante: aunque el emisor puede continuar, el receptor se bloquea hasta que llega el mensaje solicitado. Es la combinacin ms til. III) Envo no bloqueante, recepcin no bloqueante: nadie debe esperar. El send no bloqueante es la forma ms natural para muchas tareas de programacin concurrente. Un posible riesgo del send no bloquente es que por error puede llevar a una situacin en la que el proceso genere mensajes repetidamente. Para el receive, la versin bloqueante es la mas natural para muchas tareas de programacin concurrente. En general, un proceso que solicita un mensaje necesitara la informacin esperada antes de continuar. DIRECCIONAMIENTO Es necesario disponer de alguna forma de especificar en la primitiva send que proceso va a recibir el mensaje. La mayora de las implementaciones permiten a los procesos receptores indicar el origen del mensaje que se va a recibir.

Los distintos esquemas para hacer referencia a los procesos en las primitivas send y receive se encuadran dentro de 2 categoras: 1) Direccionamiento directo: la primitiva send incluye una identificacin especfica del proceso de destino. La primitiva receive se puede gestionar de 2 formas:

Una posibilidad requiere que el proceso designe explcitamente un proceso emisor. El proceso debe conocer de antemano de que proceso espera un mensaje. En otros casos es imposible especificar el proceso de origen por anticipado.

2) Direccionamiento indirecto: los mensajes no se envan directamente del emisor al receptor, sino a una estructura de datos compartidos formada por colas, que pueden guardar los mensajes temporalmente, que se denominan BUZONES (mailboxes). Para que 2 procesos se comuniquen, uno enva mensajes al buzn apropiado y el otro los retira. Una ventaja de este tipo de direccionamiento es que se desacopla a emisor y receptor, asegurando mayor flexibilidad en el uso de mensajes. Relacin entre emisores y receptores

UNO A UNO: permite que se establezca un enlace privado entre 2 procesos. Asla su interaccin de injerencias errneas de otros procesos. MUCHOS A UNO: resulta til para interacciones cliente-servidor. En este caso el buzn se llama puerto. UNO A MUCHOS: permite un emisor y varios receptores.

La asociacin de procesos a buzones puede ser ESTATICA o DINAMICA. Los puertos suelen estar asociados estticamente con algn proceso en particular. El puerto se crea y se asigna al proceso permanentemente. Una relacin de UNO A UNO se define de forma esttica y permanentemente. Cuando hay varios emisores, la asociacin a un BUZON puede realizarse dinmicamente. Se pueden utilizar primitivas como CONECTAR o DESCONECTAR. Propiedad del buzn. en el caso de 1 puerto, normalmente pertenece y se crea por el RECPTOR. Entonces cuando se destruye el proceso, tambin se destruye el puerto. Para los buzones en general el S.O. ofrece un servicio de creacin de buzones. Son considerados como propiedad del proceso creador en cuyo caso se destruyen junto con el proceso, o como propiedad del S.O., en este caso se necesita una orden explicita para destruir el buzn. FORMATO DE MENSAJES Para algunos S.O. los diseadores han elegido mensajes cortos y tamaos fijos para minimizar procesamiento y coste de almacenamiento. Si se van a pasar una gran cantidad

de datos, estos pueden ponerse en un archivo y el mensaje simplemente har referencia a este archivo. Una solucin ms flexible es utilizar mensajes de longitud variable. DISCIPLINA DE COLA La disciplina de cola ms simple es FIFO, pero esta puede no ser suficiente para mensajes ms urgentes que otros. Una opcin es habilitar la especificacin de prioridades de los mensajes, en funcin del tipo de mensajes o por designacin del emisor. Otra es permitir al receptor examinar la cola de mensajes y seleccionar el mensaje a recibir a continuacin. EXCLUSION MUTUA Con el siguiente algoritmo de muestra una forma de usar el PASO DE MENSAJES para cumplir la exclusin mutua. Se usan RECEIVE bloqueantes y SEND no bloqueantes. Unos procesos concurrentes comparte un BUZON, EXMUT, que puede ser usado por todos los procesos. EXMUT (buzn) tiene inicialmente un nico mensaje nulo. Un proceso que requiere entrar en su seccin crtica intenta: 1) recibir el mensaje. Si el EXMUT(buzn) esta vaco, se bloquea el proceso. 2) Una vez que consigui el mensaje, ejecuta su seccin crtica y devuelve el mensaje al buzn. El mensaje funciona como un testigo(TOKEN) que se pasa de proceso a otro. Esta tcnica supone que si hay ms de un proceso ejecutando la accin RECEIVE concurrentemente, entonces:

Si hay un mensaje, se entrega solo a uno de los procesos y los dems se bloquean. Si el buzn esta vaco, todos se bloquean cuando hay un mensaje, solo se activara y tomara el mensaje uno de los procesos bloqueados. PROBLEMA DE LOS LECTORES/ESCRITORES

Descripcin del problema: Existe un rea de datos compartida entre una serie de procesos, algunos slo leen los datos (lectores) y otros slo escriben datos (escritores). El problema es satisfacer las siguientes condiciones: 1. Cualquier nmero de lectores puede leer el archivo simultneamente. 2. En el archivo slo puede escribir un escritor en cada instante.

3. Si un escritor est accediendo al archivo, ningn lector puede leerlo. El problema general de exclusin mutua, consiste en permitir a cualquiera de los procesos (lectores o escritores) leer o escribir en el rea de datos. Esto hace necesario declarar cualquier acceso como una seccin crtica donde los procesos tendran que acceder uno a uno producindose intolerables retrasos, adems se debe impedir que los escritores interfieran unos con otros y tambin que se realicen consultas mientras se llevan a cabo modificaciones Aplicar la solucin general al problema de los lectores/escritores sera inaceptablemente lenta. En este caso ms restrictivo es posible crear soluciones ms eficientes. A continuacin se examinan dos soluciones al problema: 1. PRIORIDAD A LOS LECTORES Es una solucin que utiliza semforos para respetar la exclusin mutua. Se permite el acceso a varios lectores, pero mientras que un escritor est accediendo a los datos compartidos, no se permite acceder a ningn escritor o lector. El primer lector que intenta acceder debe esperar en el semforo, Cuando haya al menos un lector, los lectores siguientes no necesitan esperar para entrar, se les da prioridad. El problema es que un escritor estar esperando mientras que haya al menos un lector leyendo, que luego podra dar paso a otro lector, en este caso el lector estar sujeto a inanicin. Se utiliza una variable global contlect para mantener el nmero de lectores y el semforo x para que la actualizacin de contlect sea consistente. El semforo esem controla el acceso al recurso compartido.

/* program lectores_escntores*/ int contlect; semforo x = 1, esem=1; void lector() { while (cierto) { wait(x); contlect++; If (contlect==1)

wait(esem); signal(x); LEER_UNIDAD(); wait(x); contlect--; If (contlect==0) signal(esem); signal(x); } } void escritor() { while (cierto) { wait(esem); ESCRIBIR_UNIDAD(); signal(esem); } } vold main() { contlect = 0; parbegln(tector, escritor); } Una solucin al problema de los lectores/escritores por medio de semforos; los lectores tienen prioridad.

2. PRIORIDAD A LOS ESCRITORES

Esta solucin garantiza que no se permitir acceder a los datos a ningn nuevo lector una vez que, al menos, un escritor haya declarado su deseo de escribir. Se utilizan los mismos semforos que en la solucin anterior y se aaden otros ms: Un semforo Isem que inhibe todas las lecturas cuando al menos un escritor desea acceder Una variable contesc que controla la activacin de Isem Un semforo y que controla la actualizacin de contesc Un semforo y que controla la actualizacin de contesc Un semforo z donde se encolan los lectores cuando ya hay uno en lsem

/* program lectores_escritores */ Int contlec, contesc; semforo x=1, y =1, z=1, esem=1, lsem=1; void lector() { while (cierto) { wait(z); wait(lsem); wait(x); contlect++; if (contlect = = 1) { wait(esem); } signal(x); signal(lsem); signal(z); LEER_UNIDAD();

wait(x); contlect--; if (contlect == 0) signal(esem); signal(x); } } void escritor() { while (cierto) { wait(y); contesc++; if (contesc = = 1) wait(lsem) ; signal(y); wait(esem); ESCRIBIR_UNIDAD(); signal(esem); wait(y); contesc--; If (contesc== 0) signal(lsem); signal(y); } } void mailn() {

contlect = contesc = 0; parbegin (lector, escritor); }