2.3.

7 Monitores
Un monitor es una colección de procedimientos, variables y estructuras de datos que
se agrupan en un tipo especial de módulo o paquete. La figura 2-33 ilustra un monitor
escrito en un lenguaje imaginario, Pidgin Pascal. Aquí no podemos utilizar C debido a
que los monitores son un concepto del lenguaje, y C no los tiene.

Los monitores tienen una importante propiedad que los hace útiles para lograr la
exclusión mutua: sólo puede haber un proceso activo en un monitor en cualquier
instante. Por lo general, cuando un proceso llama a un procedimiento de monitor, las
primeras instrucciones del procedimiento comprobarán si hay algún otro proceso
activo en un momento dado dentro del monitor. De ser así, el proceso invocador se
suspenderá hasta que el otro proceso haya dejado el monitor.
Cuando un procedimiento de monitor descubre que no puede continuar (por ejemplo,
el productor encuentra el búfer lleno), realiza una operación wait en alguna variable de
condición (por decir, llenas). Esta acción hace que el proceso que hace la llamada se
bloquee. También permite que otro proceso que no haya podido entrar al monitor
entre ahora.
Aunque Pidgin Pascal es un lenguaje imaginario, algunos lenguajes de programación
reales también permiten implementar monitores, aunque no siempre en la forma
diseñada por Hoare y Brinch Hansen. Java es uno de esos lenguajes. Java es un
lenguaje orientado a objetos que soporta hilos a nivel usuario y también permite
agrupar métodos (procedimientos) en clases. Al agregar la palabra clave synchronized
a la declaración de un método, Java garantiza que, una vez un hilo ha empezado a
ejecutar ese método, no se permitirá que ningún otro hilo empiece a ejecutar ningún
otro método synchronized de ese objeto.
Estos mismos lenguajes tampoco tienen semáforos, pero es fácil agregarlos: todo lo
que necesitamos hacer es agregar dos rutinas cortas en lenguaje ensamblador a la
biblioteca para emitir las llamadas al sistema up y down. Los compiladores ni siquiera
tienen que saber que existen. Desde luego que los sistemas operativos tienen que
saber acerca de los semáforos, pero si tenemos al menos un sistema operativo basado
en semáforos, podemos escribir los programas de usuario para este sistema en C o
C++.
Otro problema con los monitores (y también con los semáforos) es que están
diseñados para resolver el problema de exclusión mutua en una o más CPUs que
tengan acceso a una memoria común. Si utilizamos un sistema distribuido que consista
en varias CPUs, cada una con su propia memoria privada, conectadas por una red de
área local, estas primitivas no se pueden aplicar. La conclusión es que los semáforos
son de un nivel demasiado bajo y los monitores no pueden usarse, excepto en algunos
lenguajes de programación. Además, ninguna de las primitivas permite el intercambio
de información entre las máquinas. Se necesita algo más.
2.3.8 Pasaje (transmisión) de mensaje
Ese “algo más” es el pasaje de mensajes (message passing). Este método de
comunicación entre procesos utiliza dos primitivas (send y receive) que, al igual que los
semáforos y a diferencia de los monitores, son llamadas al sistema en vez de
construcciones del lenguaje. Como tales, se pueden colocar con facilidad en
procedimientos de biblioteca, como:
-send(destino, &mensaje); y receive(origen, &mensaje);
La primera llamada envía un mensaje a un destino especificado y la segunda recibe un
mensaje de un origen especificado. Si no hay un mensaje disponible, el receptor se
puede bloquear hasta que llegue uno. De manera alternativa, puede regresar de
inmediato con un código de error.
Los sistemas de paso de mensajes tienen muchos problemas y cuestiones de diseño
que presentan un reto y no surgen con los semáforos o monitores, en especial si los
procesos que se están comunicando se encuentran en distintas máquinas.
perder mensajes en la red. Para protegerse contra los mensajes perdidos, el emisor y
el receptor pueden acordar que, tan pronto como haya recibido un mensaje, el
receptor enviará de vuelta un mensaje especial de acuse de recibo
(acknowledgement). Si el emisor no ha recibido el acuse dentro de cierto intervalo de
tiempo, vuelve a transmitir el mensaje. Ahora considere lo que ocurre si el mensaje se
recibió en forma correcta, pero se pierde el mensaje de acuse que se envía de vuelta al
emisor. Éste volverá a transmitir el mensaje, por lo que el receptor lo recibirá dos
veces. Es esencial que el receptor pueda diferenciar un mensaje nuevo de la
retransmisión de uno anterior. Por lo general, este problema se resuelve colocando
números de secuencia consecutivos en cada mensaje original. Si el receptor recibe un
mensaje que contenga el mismo número de secuencia que el mensaje anterior, sabe
que el mensaje es un duplicado que se puede ignorar. La comunicación exitosa a la
cara del pasaje de mensajes sin confiabilidad constituye una gran parte del estudio de
las redes de computadoras.
2.3.9 Barreras
Algunas aplicaciones se dividen en fases y tienen la regla de que ningún proceso puede
continuar a la siguiente fase sino hasta que todos los procesos estén listos para
hacerlo. Para lograr este comportamiento, se coloca una barrera al final de cada fase.
Cuando un proceso llega a la barrera, se bloquea hasta que todos los procesos han
llegado a ella.

En la figura 2-37(a) podemos ver cuatro procesos que se acercan a una barrera. Lo que
esto significa es que sólo están calculando y no han llegado al final de la fase actual
todavía. Después de cierto tiempo, el primer proceso termina todos los cálculos
requeridos durante la primera fase. Después ejecuta la primitiva barrier, por lo general
llamando a un procedimiento de biblioteca. Después el proceso se suspende. Un poco
después, un segundo y luego un tercer proceso, terminan la primera fase, ejecutando
también la primitiva barrier. Esta situación se ilustra en la figura 2-37(b). Por último,
cuando el último proceso (C) llega a la barrera se liberan todos los procesos, como se
muestra en la figura 2-37(c).