Competencia de ProcesosDr. Alonso Ramírez Manzanares

21-Sep-2010

Monitores

Existe un problema con los semaforos, ¿qué pasa si por error intercambiamos el orden de estos semáforos?

mutex se decrementa antes que empty.Si el buffer está lleno, entonces el productor se bloquea con mutex puesto en 0, cuando el consumidor quiera accesar el

buffer, se va a bloquear y ambos quedan en bloqueo mutuo para siempre (¡¡esto es responsabilidad del programador!!).

MonitoresA fin de facilitar la escritura de programas correctos se propuso una primitiva de sincronización de mas alto

nivel llamada monitor.

Es una colección (o paquete especial) de procedimientos variables y estructuras de datos.

Los procesos pueden invocar los procedimientos del monitos en el momento que deseen, pero no pueden acceder a las estructuras de datos internas del monitor.

Y SOLO UN PROCESO PUEDE ESTAR ACTIVO EN UN MONITOR EN UN MOMENTO DADO.

MonitoresEjemplo:

El compilador sabe que es una estructura especial: (continua ...)

MonitoresDe tal forma que cuando un proceso invoca a un procedimiento de monitor, las primeras instrucciones del procedimiento verifican si existe algun otro proceso activo en ese momento dentro del monitor. Si es así, el proceso invocador se suspende hasta que el otro proceso abandona el monitor.

La exclusion multiple se implementa por lo general con un semáforo binario. Pero de esto se encarga el compilador y no el usuario (por lo tanto es mas seguro).

La idea es programas las regiones críticas como procedimientos del monitor.

Monitores

Ya tenemos garantizada la exclusion mutua, pero ahora necesitamos sincronización (bloqueo cuando no pueden continuar). Para eso agregamos las señales:

Agregamos variables de condición con 2 operaciones asocadas a ellas:

WAIT: se ejecuta cuando un procedimiento de monitor descubre

que no puede continuar, con alguna variable de condición (por ejemplo full). Esto hace que el proceso invocador se bloquee y asi permite que otro proceso entre al monitor.

continua...

Monitores

SIGNAL se ejecuta para despertar procesos que están en espera con respecto a una variable de condición (por ejemplo full). Para evitar que 2 procesos estén adentro del monitor (despertador y despertado) al mismo tiempo, el proceso que ejecutó signal debe de salir inmediatamente del monitor, es decir debe de ser su última instrucción.

Monitores

Las variables de condición no son acumuladores. Por lo tanto una señal SIGNAL se puede perder.

Entonces la señal WAIT tiene que venir siempre antes que SIGNAL.

Esta regla simplifica la implementación.

P-C Implementado en Monitores

Monitores

¿Cuál es la ventaja de WAIT y SIGNAL con respecto a SLEEP y WAKEUP?

Que con monitores no puede suceder que mentras uno apenas va a dormirse, el otro ya está tratando de despertarlo.

La exclusión mutua dentro del monitor garantiza que, en este caso, es 1er proceso va a completar WAIT antes de que otro proceso ejecute SIGNAL.

MonitoresLa desventaja de los monitores es que son un concepto de lenguajes de programación.

C y pascal no tienen monitores.

Podemos implementar semáforos fácilmente en estos lenguajes.

Otro problema es que los monitores y los semáforos no funcionan en sistemas distribuidos donde la memoria no es compartida (clusters conectados por redes).

CONCLUSON: LOS SEMAFOROS SON DE MUY BAJO NIVEL Y LOS MONITORES SOLO EXISTEN EN MUY POCOS LENGUAJES DE PROGRAMACION. NECESITAMOS OTRA COSA.

Transferencia de Mensajes

Esto es la “otra cosa”.

Es un metódo de comnicación entre procesos que usa las primitivas (llamadas al sistema y no construcciones de lenguaje, como los semáforos):

send(destino,&mensaje);

receive(origen,&mensaje);

donde origen puede ser cualquiera (ANY).

Transferencia de Mensajes

Si no hay un mensaje disponible el receptor se puede bloquear hasta que llegue o bien puede salir inmediatamente con un código de error.

Transferencia de MensajesLos sistemas tienen varios problemas:

Un mensaje se puede perder en la red.

Entonces se puede implementar que el receptor confirme recepción con un acuse de recibo AK.

Si el emisor no recibe nada en algun tiempo establecido, entonces reenvia el mensaje.

La confirmacíon se puede perder.

El receptor recibe el mensaje 2 veces, y debe de ser capaz de discernir entre una retransmision y un mensaje nuevo (se usan números consecutivos en cada mensaje).

Transferencia de Mensajes

También se tiene que resolver el nombre de procesos, de tal forma que no sean ambiguos (cada uno debe tener nombre diferente).

Otra cuestión importante es la verificación de autenticidad (no aceptar mensajes de impostores).

Tambien es deseable, por cuestiones de rendimiento, usar localmente semaforos o monitores y en ambientes distribuidos mensajes (que son lentos).

Transferencia de Mensajes

Como resolvemos el problema del Prod-Cons con mensajes y sin compartir memoria:

Suponemos que todos los mensajes miden el mismo tamaño.

El SO coloca en buffers los mensajes enviados pero aún no recibidos.

Esta solucion usa N mensajes, analogo a las N ranuras de antes, pero ahora en memoria compartida.

Prod-Cons con mensajes