CONCURRENCIA:: EXCLUSIN MUTUA Y SINCRONIZACIN.

ndice
Capitulo 4 Exclusin:: Concurrencia y sincronizacin. o 4.1 Principios generales de concurrencia. o 4.2 Exclusin mutua: soluciones por software.

o 4.3 Exclusin mutua: soluciones por hardware.

o 4.4 Semforos o 4.5 Monitores o 4.6 Paso de mensajes. o 4.7 Problema de los lectores/escritores.

 Los conceptos claves en los que se basan los sistemas operativos modernos

son el de proceso y el de hilo. Los temas fundamentales de diseo de sistemas operativos estn relacionados con la gestin de procesos:

o Multiprogramacin: Es la gestin de varios procesos dentro de un sistema

monoprocesador.
o Multiproceso: Es la gestin de varios procesos dentro de un sistema

multiprocesador.
o Proceso distribuido: Es la gestin de varios procesos que ejecutan en

sistemas de computadores mltiples y remotas.

Concurrencia.

La concurrencia es el punto clave de los tres campos anteriores y

fundamentales para el diseo de sistemas operativos. La concurrencia comprende un gran nmero de cuestiones de diseo, incluyendo 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.

1. void 2. 3. 4. 5. 6. 7.

ejemplo (void) { printf (Digite un nmero: ); scanf ( %d, &pos_comp); pos_comp += 10; printf (El nmero digitado ms 10 es: %d, pos_comp);

8.
9.

return;
}

 La concurrencia puede presentarse en tres contextos diferentes:

o Varias aplicaciones: La multiprogramacin se cre para permitir que el

tiempo de procesador de la mquina fuese compartido dinmicamente entre varios trabajos o aplicaciones activas.
o 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.
o 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.

Principios generales de concurrencia.

En un sistema multi-programado con un nico procesador, los procesos se

intercalan en el tiempo para dar la apariencia de ejecucin simultnea. Aunque no se consigue un proceso paralelo real y aunque se produce una cierta sobrecarga en los intercambios de procesos de un sitio a otro, la ejecucin intercalada produce beneficios importantes en la eficiencia del procesamiento y en la estructuracin de los programas.
P1

P2

P3

Intercalacin.

 En un sistema con varios procesadores, no solo es posible intercalar los

procesos, sino tambin superponerlos. A primera vista, podra parecer que la intercalacin y la superposicin representan formas de ejecucin muy diferentes y que introducen problemas distintos. De hecho, ambas tcnicas pueden contemplarse como ejemplos de proceso concurrente y ambas plantean los mismos problemas. En el caso de un sistema monoprocesador, los problemas creados por la multiprogramacin parten del hecho de que la velocidad relativa de ejecucin de los procesos no puede predecirse
P1 P2

P3

Intercalacin y Superposicin.

 Depende de la actividad de otros procesos, de la forma en que el sistema

operativo trata las interrupciones y de las polticas de planificacin. As surgen las siguientes dificultades:
o La comparticin de recursos globales est llena de riesgos. o Para el sistema operativo resulta difcil asignar los recursos de forma optima. o Resulta difcil localizar un error de programacin porque los resultados no

son normalmente reproducibles.

 Todas las dificultades anteriores se presentan tambin en los sistemas

multiprocesador, ya que tambin en ellos es impredecible la velocidad relativa de ejecucin de los procesos. Un sistema multiprocesador debe solucionar, adems, los problemas originados por el hecho de que varios procesos puedan estar ejecutando a la vez.

Exclusin mutua:: soluciones por software.

Pueden implementarse soluciones de software para los procesos concurrentes

que ejecuten en mquinas monoprocesador o multiprocesador con una memoria principal compartida. Normalmente, estas soluciones suponen que existe una exclusin mutua elemental en el acceso a memoria.

Es decir, los accesos simultneos (lecturas y/o escrituras) a la misma posicin de memoria se hacen en serie, por medio de algn tipo de rbitro de memoria, aunque el orden en el que se conceden los accesos no se conoce por adelantado. Aparte de esto, no se requiere ningn soporte del hardware, del sistema operativo o del lenguaje de programacin.

 Algoritmo de Dekker .

Dijkstra present un algoritmo de exclusin mutua para dos procesos que dise el matemtico holands Dekker. Segn Dijkstra, la solucin se desarrolla por etapas. Este mtodo tiene la ventaja de ilustrar la mayora de los errores habituales que se producen en la construccin de programas concurrentes. A medida que se construya el algoritmo, se emplearn algunas ilustraciones pintorescas tomadas de Ben-Ari para escenificar la accin

o Primer intento.

Como se mencion anteriormente, cualquier intento de exclusin mutua debe depender de algunos mecanismos bsicos de exclusin en el hardware. El ms habitual es la restriccin de que solo se puede realizar un acceso a una posicin memoria en cada instante. Como metfora de este arbitrio de la memoria, se muestra el protocolo del igl. Tanto la entrada como el mismo igl son tan pequeos que solo puede entrar una persona a la vez en el igl. Dentro, hay una pizarra en la que se puede escribir un nico valor.

El protocolo es el siguiente. Un proceso (P0 P1) que desee ejecutar su seccin crtica entra primero en el igl y examina la pizarra. Si su nmero est escrito en ella, el proceso puede abandonar el igl y continuar con su seccin critica. En otro caso, abandona el igl y se ye obligado a esperar. De vez en cuando, el proceso vuelve a entrar en el igl para mirar la pizarra.

Esta operacin la repite hasta que se le permite entrar en su seccin crtica. Este procedimiento se denomina espera activa porque un proceso frustrado no puede hacer nada productivo hasta que obtiene permiso para entrar en su seccin crtica. En su lugar, debe persistir y comprobar peridicamente el igl; as pues, consume tiempo del procesador (est activo) mientras espera su oportunidad.

Despus de que un proceso haya obtenido acceso a su seccin crtica y una vez que termine con ella, debe volver al igl y escribir el nmero del otro proceso en la pizarra.

En trminos formales, hay una variable global compartida:

Esta solucin garantiza el cumplimiento de la exclusin mutua. Hay dos inconvenientes en esta solucin. Primero, los procesos deben alternarse de forma estricta en el uso de sus secciones crticas; as pues, el ritmo de ejecucin viene dictado por el ms lento. Si P0 usa su seccin crtica solo una vez por hora, pero P1 quiere usarla con una tasa de 1000 veces por hora, P1 est obligado a adoptar el ritmo de P0. Un problema mucho ms seno es que si un proceso falla (por ejemplo, se lo come un oso polar en su camino hacia el igl), el otro proceso se bloquea permanentemente. Esto es cierto tanto si un proceso falla en su seccin critica como fuera de ella.

La estructura anterior es la de una corrutina. Las corrutinas se disearon para poder pasar el control de la ejecucin de un proceso a otro. Aunque es una tcnica de estructuracin til para un solo proceso, no resulta apropiada para dar soporte al proceso concurrente.

o Segundo intento.

El problema de la primera tentativa es que se almacenaba el nombre del proceso que poda entrar en su seccin crtica cuando, de hecho, lo que hace falta es tener informacin del estado de ambos procesos. En realidad, cada proceso debera tener su propia llave de la seccin crtica para que, si un oso polar elimina a uno de ellos, el otro pueda seguir accediendo a su seccin crtica.

Esta filosofa queda ilustrada en la siguiente figura. Cada proceso tiene ahora su propio igl y puede mirar ha pizarra del otro, pero no modificarla. Cuando un proceso desea entrar en su seccin critica, comprueba peridicamente la pizarra del otro hasta que encuentra escrito en ella falso, lo que indica que el otro proceso no est en su seccin crtica. Entonces, se dirige rpidamente hacia su propio igl, entra y escribe cierto en la pizarra. El proceso puede ahora continuar con su seccin crtica. Cuando deja su seccin crtica, cambia su pizarra para que ponga falso.

La variable global compartida es ahora:

Ahora, si uno de los procesos falla fuera de la seccin crtica, incluyendo el cdigo para dar valor a las seales, el otro proceso no se queda bloqueado. De hecho, el otro proceso puede entrar en su seccin crtica tantas veces como quiera, porque la seal del otro proceso est siempre puesta a falso. Sin embargo, si un proceso falla en su seccin crtica, el otro proceso est bloqueado permanentemente.

En realidad, esta solucin es, si acaso, peor que el primer intento, pues no siempre se garantiza la exclusin mutua. Considrese la siguiente secuencia: P0 ejecuta la sentencia while y encuentra seal [1] a falso. P1 ejecuta la sentencia while y encuentra seal [0] a falso.

P0 pone seal [0] a cierto y entra en su seccin crtica.

P1 pone seal [1] a cierto y entra en su seccin crtica. Puesto que ambos procesos estn en sus secciones crticas, el programa es incorrecto. El problema est en que la solucin propuesta no es independiente de

la velocidad de ejecucin relativa de los procesos.

o 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. Quiz se pueda arreglar este problema con un simple intercambio de dos lneas:

Como antes, si un proceso falla dentro de la seccin crtica, incluyendo el cdigo para dar valor a las seales que controlan el acceso a la seccin crtica, el otro proceso se bloquea y si un proceso falla fuera de su seccin critica, el otro proceso no se bloquea. Esta solucin garantiza la exclusin mutua, pero origina un problema ms. Si ambos procesos ponen sus seales a cierto antes de que ambos hayan ejecutado la sentencia while, cada uno pensar que el otro ha entrado en su seccin critica. El resultado es un interbloqueo.

o Cuarto intento.

En el tercer intento, un proceso fijaba su estado sin conocer el estado del otro. El interbloqueo se produce porque cada proceso puede insistir en su derecho para entrar en la seccin crtica; no hay opcin para volver atrs desde esta situacin. Se puede intentar arreglar esto haciendo que los procesos sean ms educados: Deben activar su seal para indicar que desean entrar en la seccin crtica, pero deben estar listos para desactivar la seal y ceder la preferencia al otro proceso:

Esta solucin se aproxima a la correcta pero todava es defectuosa. La exclusin mutua an est garantizada con un razonamiento similar al seguido en el estudio del tercer intento.

o Una solucin correcta.

Hay que poder observar el estado de ambos procesos, que viene dado por la variable seal. Pero, como demuestra el cuarto intento, esto no es suficiente. De algn modo, se hace necesario imponer algn orden en la actividad de los dos procesos para evitar el problema de cortesa mutua que se acaba de observar. La variable turno del primer intento puede usarse en esta labor; en este caso, la variable indica qu proceso tiene prioridad para exigir la entrada a la seccin critica.

Es posible describir esta solucin en trminos de igles fijndose en la siguiente figura. Ahora hay un igl rbitro con una pizarra llamada turno. Cuando P0 quiere entrar en su seccin critica, pone su seal a cierto. A continuacin, va y mira la seal de P1. Si sta est puesta a falso, P0 puede entrar inmediatamente en su seccin crtica. En otro caso, P0 va a consultar al rbitro. Si encuentra el turno = 0, sabe que es momento de insistir y comprueba peridicamente el igl de P1. Este otro se percatar en algn momento de que es momento de ceder y escribir falso en su pizarra, permitiendo continuar a P0. Despus de que P0 haya ejecutado su seccin crtica, pone su seal a falso para liberar la seccin crtica y pone turno a 1 para traspasar el derecho de insistir a P1

 Algoritmo de Peterson.

El algoritmo de Dekker resuelve el problema de la exclusin mutua pero con un programa complejo, difcil de seguir y cuya correccin es difcil de demostrar. Peterson 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.

Exclusin mutua:: soluciones por hardware.

Optimistas o Consideran que lo mas probable es que no haya conflictos, y si los hay sea

en nmero reducido, por lo que permiten cualquier acceso a la variable compartida. En caso de conflicto, mantienen la integridad del sistema descartando las actualizaciones.

 Pesimistas. o Bloquean todo aquello que pueda interferir. o Actualizan la variable. o Desbloquean lo bloqueado al principio.

 Inhabilitacin de interrupciones.

o En una mquina monoprocesador, la ejecucin de procesos concurrentes no

puede superponerse.
o Un proceso continuar ejecutndose hasta que solicite un servicio el sistema

operativo o hasta que sea interrumpido.

o Para garantizar la exclusin mutua, es suficiente con impedir que un proceso

sea interrumpido.

 Semforos. o El principio fundamental es que los 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.
o Para la sealizacin se usan variables especiales llamadas semforos "S"

 Monitores.

o 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.
o La estructura de monitor se ha implementado en varios lenguajes de

programacin como: Pascal concurrente, Modulo-2, Java, etc.

Semforos.

Un semforo es una estructura diseada para sincronizar dos o ms threads o

procesos, de modo que su ejecucin se realice de forma ordenada y sin conflictos entre ellos.

 Son una solucin, del tipo soporte al sistema operativo para garantizar la

exclusin mutua.
Un semforo nos sirve para poder permitir o restringir a los procesos o hilos el

acceso a algn recurso compartido.

 Operaciones bsicas.

o Los semforos cuentan con operaciones bsicas, una de ellas es para

reservarlo y la otra para liberarlo, wait(espera) y signal(seal) respectivamente, equivalente down y up.

o Existe una tercera operacin que consiste en inicializar el semforo.

o Existen algunos semforos que manejan una cola de espera.

 Wait, Top, Down o Espera.

o Decremento en una unidad el semforo. o Bloquea hilo/proceso si el semforo es menor que cero, sino entonces

permite a hilo/proceso continuar.

o Llamada W(semforo) o down(semforo).

 Signal, Up o Seal.
o Incrementa semforo en uno y si hay algn proceso esperando lo despierta. o Existe un valor mximo para incrementar el semforo, este no se va a infinito. o Llamada S(semforo) o up(semforo).

 Inicializador. o Los semforos pueden ser de 2 tipos: Binarios o Generales(Contadores). o La operacin de inicializador definir si el semforo ser binario o no, es

decir, si se inicializa con 1, el semforo ser binario ya que solo podr manejar un recurso compartido, en caso de tener N recursos compartidos se inicializara con N.
o Si tenemos N procesos inicializamos un semforo para que solo N

procesos acceda a un recurso compartido.

 Semforos con manejo de cola. o Existen semforos que tienen la operacin de manejar una cola del tipo FIFO

(PEPS)para llevar el control de los procesos que estn solicitando los recursos, as cuando se liberen los recursos estos puedan asignarle dicho recurso al primer proceso que lo solicito,

o Desventajas No se puede imponer el uso correcto de los Down y Up. No existe una asociacin entre el semforo y el recurso.

Entre Down y Up el usuario puede realizar cualquier operacin con

el recurso.

Monitores.

Los semforos son una herramienta bsica, pero potente y flexible, para hacer

cumplir la exclusin mutua y coordinar procesos. Sin embargo, puede resultar difcil construir un programa correcto por medio de semforos. La dificultad est en que las operaciones wait y signal deben distribuirse por todo el programa y no es fcil advertir el efecto global de estas operaciones sobre los semforos a los que afectan.

 Los monitores son estructuras de un lenguaje de programacin que ofrecen

una funcionalidad equivalente a La de los semforos y que son ms fciles de controlar. El concepto fue definido formalmente por primera vez en [HOAR74]. La estructura de monitor se ha implementado en varios lenguajes de programacin, incluido Pascal Concurrente, Pascal-plus, Modula-2 y Modula-3. Ms recientemente, se han implementado como una biblioteca de programas. Esto permite poner cierres de monitor a objetos cualesquiera. En particular, para algo parecido a una lista enlazada, se puede querer bloquear todas las listas enlazadas con un solo cierre o bien tener un cierre para cada elemento de cada lista.

 Monitores con seales. o Un monitor es un modulo de software que consta de uno o ms procedimientos, una

secuencia de inicializacin y unos datos locales. Las caractersticas bsicas de un monitor son las siguientes:
Las variables de datos locales estn solo accesibles para los procedimientos del

monitos y no para procedimientos externos.

Un proceso entra en el monitor invocando a uno de sus procedimientos. Solo un proceso puede estar ejecutando en el monitor en un instante proceso

que haya invocado al monitor quedara suspendido mientras espera a que el monitor est disponible.

o Las dos primeras caractersticas recuerdan a las de los objetos del software

orientado a objetos donde puede ser implementado fcilmente.

o Si se cumple la norma de un proceso cada vez, el monitor puede ofrecer un

servicio de exclusin mutua, de tal forma que una estructura de datos compartida puede protegerse situndola dentro de un monitor.

o Para que resulten tiles en el proceso concurrente, los monitores deben incluir

herramientas de sincronizacin. Por ejemplo, supngase que un proceso llama a un monitor y, mientas est en el monitor, debe suspenderse hasta que se cumpla alguna condicin. Hace falta un servicio para que el proceso no solo este suspendido, sino que libere el monitor y otro proceso pueda entrar.

Ms tarde, cuando se cumpla la condicin y el monitor est de nuevo disponible, el proceso pueda reanudarse y tiene que permitirle volver a entrar en el monitor en el punto de la suspensin.

Paso de mensajes.
Paso de mensajes. o Un monitor proporciona sincronizacin por medio de las variables de

condicin que se incluyen dentro del monitor y son accesibles slo desde dentro. Hay dos funciones para operar las variables de condicin:
Wait(c): Suspende la ejecucin del proceso llamado bajo la condicin c. El

monitor esta ahora disponible para ser usado por otro proceso.
Signal(c): Reanuda la ejecucin de algn proceso suspendido despus de

un wait bajo la misma condicin. Si hay varios procesos, elige uno de ellos; si no hay ninguno, no hace nada.

o Ntese que las operaciones de monitor wait/signal son diferentes de la de los

semforos. Si un proceso de un monitor ejecuta un signal y no hay tareas esperando en la variable de condicin, el signal se pierde.

o Como con los semforos, 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 la condicin correspondiente permanecern colgados permanentemente. La ventaja que tienen los monitores sobre los semforos es que todas las funciones de sincronizacin estn confinadas dentro del monitor. De este modo, es sencillo verificar que la sincronizacin se ha realizado correctamente y detectar los fallos. Es ms, una vez que un monitor est correctamente programado, el acceso al recurso protegido es correcto para todos los procesos. Con los semforos, en cambio, el acceso al recurso es correcto slo si todos los procesos que acceden al recurso estn correctamente programados.

 Monitores con notificacin y difusin. o La definicin que hace Hoare de los monitores [HOAR74] exige que, si hay al

menos un proceso en una cola de condicin, un proceso de dicha cola deber ejecutar en cuanto otro proceso ejecute un csignal para la condicin. As pues, el proceso que ejecuta el csignal debe salir inmediatamente del monitor o suspenderse en el monitor.

o Son varios los inconvenientes de esta solucin:

1. Si el proceso que ejecuta el csignal no abandona el monitor, hacen falta

dos cambios de contexto adicionales: uno para suspender el proceso y otro para reanudarlo cuando el monitor quede disponible.
2. La planificacin de procesos asociada con las seales debe ser muy

fiable. Cuando se ejecuta un csignal, debe activarse inmediatamente un proceso de la cola de la condicin correspondiente y el planifcador debe asegurarse de que ningn otro proceso entra al monitor antes de la activacin. Si no es as, la condicin bajo la que se ha activado el proceso podra cambiar. Por ejemplo, en la figura 4.24, cuando se ejecuta un csignal(no_ vaco), un proceso de la cola no _ vaci debe activarse antes de que un nuevo consumidor entre al monitor. Otro ejemplo es que un proceso productor puede aadir un carcter a un buffer vaco y despus fallar antes de dar la seal; cualquier proceso de la cola no_vaco permanecer colgado

o Lampson y Redell desarrollaron una definicin diferente de monitores para el

lenguaje Mesa [LAMP80]. Su mtodo supera los problemas comentados y ofrece algunas ampliaciones de utilidad. La estructura de monitores de Mesa se usa tambin en el lenguaje Modula-3 de programacin de sistemas [CARD89, HARB90, NELS91]. En Mesa, la primitiva csignal se reemplaza por cnotify, con la siguiente interpretacin:
o Cuando un proceso que est en un monitor ejecuta cnotify(x), origina una

notificacin hacia la cola de la condicin x, pero el proceso que da la seal puede continuar ejecutando. El resultado de la notificacin es que el proceso de la cabeza de la cola de condicin ser reanudado en el futuro cercano, cuando el monitor est disponible. Sin embargo, puesto que esto no garantiza que ningn otro proceso entre al monitor antes que el proceso que espera, el proceso que espera debe volver a comprobar la condicin. Por ejemplo, los procedimientos en el monitor buffer _ acotado tendran ahora el siguiente cdigo :

Una ventaja de los monitores de Lampson/Redell sobre los de Hoare es que el mtodo de Lampson/Redell es menos propenso a errores. En el enfoque de Lampson/Redell, debido a que cada procedimiento comprueba la variable del monitor despus 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. El programa que recibe la seal comprobar la variable pertinente y, si no se cumple la condicin deseada, continuar esperando.

o Otra ventaja de los monitores de Lampson/Redell es que se prestan a un

mtodo ms modular de construccin de programas. Por ejemplo, considrese la implementacin de una asignacin de buffers. Hay dos niveles de condicin que deben satisfacerse para los procesos secunciales cooperantes:
Nivel 1. Estructuras de datos consistentes. Esto 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.
Nivel 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.
Cuando los procesos interactan unos con otros, se deben satisfacer dos

requisitos bsicos:
o Sincronizacin.

Cumplimiento de exclusin mutua

o Comunicacin. Intercambio de informacin.

o Un mtodo para lograr dichas funciones es el paso de mensajes.

o VENTAJA: Se presta para ser implementado en sistemas de cmputo

distribuido, multiprocesador, y monoprocesador con memoria compartida.

 Primitivas del paso de mensajes. o La funcionalidad real del paso de mensajes se ofrece por medio de dos

primitivas:
send (destino, mensaje). receive (origen, mensaje).

o Un proceso enva informacin en forma de un mensaje a otro proceso

designado como destino ejecutando la primitiva send.

o Un proceso recibe informacin ejecutando la primitiva receive, que indica el

proceso origen y el mensaje.

 Primitiva send. o Cuando se ejecuta una primitiva send en un proceso, las posibilidades son:

El proceso emisor se bloquea hasta que se recibe el mensaje.

El proceso emisor no se bloquea, y continua sin importar si se recibe el

mensaje.

 Primitiva receive. o Cuando un proceso ejecuta una primitiva receive, hay dos posibilidades: Si previamente se ha enviado algn mensaje es recibido y contina la

ejecucin.
Si no hay ningn mensaje esperando

(a) el proceso se bloquea hasta que llega un mensaje, o,

(b) el proceso contina ejecutando, abandonando el intento de recepcin.

o Tanto el emisor como el receptor pueden ser bloqueantes o no bloqueantes

 Combinaciones de primitivas.

o Son habituales las siguientes tres combinaciones :

Envo bloqueante, recepcin bloqueante: Tanto el emisor como el receptor

se bloquean hasta que se entrega el mensaje (rendezvous).

Permite una fuerte sincronizacin entre procesos.

 Envo no bloqueante, recepcin bloqueante: el emisor puede continuar,

pero el receptor se bloquea hasta que llega el mensaje solicitado. Permite que un proceso enve uno o ms mensajes a varios destinos tan rpido como sea posible. Un proceso que debe recibir un mensaje antes de poder hacer alguna funcin til tiene que bloquearse hasta que llegue el mensaje (ejemplo: proceso servidor que ofrece un servicio o un recurso a otros procesos).
Envo no bloqueante, recepcin no bloqueante: Nadie debe esperar.
(cualquier sistema concreto implementa slo una o dos combinaciones)

o El send no bloqueante es la forma ms natural para muchas tareas de

programacin concurrente.
Por ejemplo:
Si se usa para solicitar una operacin de salida (como una impresin) permite al proceso solicitante realizar la solicitud en forma de mensaje y

continuar.

o Un posible riesgo del send no bloqueante:

Errores pueden llevar a que el proceso genere mensajes repetidamente. Como no hay bloqueo para hacer entrar en disciplina al proceso, esos

mensajes pueden consumir recursos del sistema en detrimento de otros procesos y del sistema operativo.
Tiempo del procesador, espacio en buffer, etc.

o El send no bloqueante carga sobre el programador el peso de determinar qu

mensaje se ha recibido.
Los procesos deben emplear mensajes de respuesta para acusar la

recepcin de un mensaje.

o Para la primitiva receive, la versin bloqueante parece ser la ms natural para

muchas tareas de programacin concurrente pero analcese el siguiente caso:

En general, un proceso que solicita un mensaje necesitar la informacin

esperada antes de continuar

si se pierde un mensaje, un proceso receptor puede quedarse bloqueado

indefinidamente.
o Esto puede resolverse por medio del receive no bloqueante.

o El riesgo del receive no bloqueante es si un mensaje se enva despus de que un proceso haya ejecutado el

correspondiente receive, el mensaje se perder.

o Una tcnica sugerida al respecto Permitir a un proceso comprobar si hay un mensaje esperando antes de

ejecutar un receive, y en permitir a un proceso especificar ms de un origen en una primitiva receive.

 Direccionamiento. o Para especificar en la primitiva send qu proceso va a recibir el mensaje. o Para especificar en la primitiva receive el origen del mensaje que se va a

recibir.
o Los distintos esquemas para hacer referencia a los procesos en primitivas

send y receive estn en dos categoras:

 Direccionamiento directo.

o La primitiva send incluye una identificacin especfica del proceso

destino.
o La primitiva receive se puede gestionar de dos formas:
El proceso designa explcitamente un proceso emisor. el proceso debe conocer de antemano de qu proceso espera un

mensaje.
suele ser eficaz para procesos concurrentes y cooperantes.

o Usar direccionamiento implcito. En este caso, el parmetro origen de la primitiva receive tendr un valor de

retomo cuando se haya realizado la operacin de recepcin.

til cuando es imposible especificar el proceso de origen por anticipado. (ejemplo - proceso servidor de impresoras, que aceptar mensajes de

solicitud de impresin de cualquier otro proceso).

 Direccionamiento indirecto. o Los mensajes no se envan directamente del emisor al receptor, sino a

una estructura de datos compartida, formada por colas, que guarda los mensajes temporalmente (buzones/mailboxes).
o Para que dos procesos se comuniquen, uno enva mensajes al buzn

apropiado el otro los toma del buzn.

o Este enfoque desacopla a emisor y receptor, lo que permite una mayor

flexibilidad en el uso de los mensajes.

o La relacin entre emisores y receptores puede ser uno a uno, Permite que se establezca un enlace privado de comunicaciones entre dos

procesos
muchos a uno, Puede resultar til para interacciones cliente/servidor, un proceso ofrece un

servicio a un conjunto de procesos (el buzn es un puerto).

uno a muchos, til para aplicaciones en las que un mensaje o informacin alguna se

difunda a un conjunto de procesos.

muchos a muchos.

o La asociacin de procesos a buzones puede ser:

Esttica Puerto se crea y asigna al proceso permanentemente.

til en relacin uno a uno, esttica y permanente.

Dinmica til cuando hay varios emisores.

Se pueden usar primitivas como conectar y desconectar con este

propsito.

o Propiedad de un buzn Un puerto pertenece y es creado por el proceso receptor. Cuando se destruye el proceso se destruir el puerto. El sistema operativo puede ofrecer un servicio de creacin de buzones de manera que los procesos pueden ser considerados como propiedad

del proceso creador, o propiedad del sistema operativo.

En el ltimo caso se necesitan rdenes explcitas para destruir el buzn.

 Formato de mensajes.

o Depende de
los objetivos del servicio de mensajera. si el servicio ejecuta en un ordenador independiente o en un sistema

distribuido.

o Para algunos sistemas operativos, los diseadores han elegido mensajes

cortos y de tamao fijo.

o En otros se permiten tamaos de longitud variable.
o Para pasar una gran cantidad de datos, los datos pueden ponerse en un

archivo y el mensaje simplemente har referencia a este archivo.

o El mensaje se divide en dos partes:

o Cabecera

alberga informacin sobre el mensaje. puede contener:

una identificacin del origen y el destino deseados

un campo de longitud un campo de tipo informacin de control adicional, como un campo apuntador, numero de secuencia, campo de prioridad

o Cuerpo

alberga la informacin del mensaje en s.

Diciplina de cola
oLa ms simple es primero en llegar/primero en salir (FIFO)

Puede no ser suficiente si algunos mensajes son ms urgentes que otros.

oUna alternativa es permitir especificacin de prioridades de los mensajes

(en funcin del tipo de mensaje o por designacin del emisor).

oOtra alternativa es permitir al receptor examinar la cola de mensajes y

seleccionar el mensaje a recibir a continuacin.

 Exclusin mutua.

o El paso de mensajes puede usarse para cumplir la exclusin mutua por ejemplo

o Supngase que se usan primitivas

receive bloqueantes bloqueantes.

send

no

o Un conjunto de procesos concurrentes

comparten un buzn, exmut

Puede ser usado por todos los

procesos para enviar y recibir.

o El buzn contiene inicialmente un

nico mensaje, de contenido nulo.

o Un proceso que desea entrar en su

seccin critica 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.

El mensaje funciona como un

testigo (token) que se pasa de un proceso a otro.

o 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 otros se bloquean.

Si el buzn est vaco, todos los

procesos se bloquean.
Cuando haya un mensaje

disponible, solo se activa y toma el mensaje uno de los procesos bloqueados.

Ejemplo adicional: Figura 4.28 (problema del productor/consumidor con buffer acotado)

Problema de los lectores/escritores.

Se define de la siguiente manera: Existe un rea de datos compartida entre una

serie de procesos. El rea de datos puede ser un archivo, un bloque de memoria principal o incluso un banco de registros del procesador. Hay algunos procesos que slo leen los datos (lectores) y otros que slo escriben datos (escritores).

 En este problema existe un determinado objeto, que puede ser un archivo, un

registro dentro de un archivo, etc., que va a ser utilizado y compartido por una serie de procesos concurrentes. Algunos de estos procesos slo van a acceder al objeto sin modificarlo, mientras que otros van a acceder al objeto para modificar su contenido. Esta actualizacin implica leerlo, modificar su contenido y escribirlo. A los primeros procesos se les denomina lectores y a los segundos se les denomina escritores.

 En este tipo de problemas existen una serie de restricciones que han de

seguirse:
o Slo se permite que un escritor tenga acceso al objeto al mismo tiempo.

Mientras el escritor est accediendo al objeto, ningn otro proceso lector ni escritor podr acceder a l.
o Se permite, sin embargo, que mltiples lectores tengan acceso al objeto, ya

que ellos nunca van a modificar el contenido del mismo. En este tipo de problemas es necesario disponer de servicios desincronizacin que permitan a los procesos lectores y escritores sincronizarse adecuadamente en el acceso al objeto.

 En este tipo de problemas es necesario disponer de servicios desincronizacin

que permitan a los procesos lectores y escritores sincronizarse adecuadamente en el acceso al objeto.