MONITORES

Primitivas de Sincronización (continuación)
MONITORES:
Primitiva de alto nivel, es a nivel de lenguajes como: ADA, PASCAL, JAVA.
Carácterísticas:
• Construcción de alto nivel.
• Estructura de datos estática:
Datos Variables de Internos Condición
una cola de procesos
cola de procesos por cada una de las
por entrar al Procedimiento C variables de condición
monitor .
.
.
Procedimiento Z
Código de Inicialización
Sólo un proceso a la vez puede acceder a los procedimientos definidos en el monitor (Exclusión Mútua). Hay procesos en cola, esperando su turno para poder entrar al Monitor.
Las variables de condición (VC) se acceden con primitivas signal(VC) wait(VC). Se usan para sincronización, duermen o despiertan un proceso. Sólo se pueden ejecutar dentro de los procedimientos definidos dentro del Monitor. Si se hace un wait a un proceso dentro del Monitor, automáticamente se libera la exclusividad de acceso de otro proceso al Monitor. Si se hace un signal, se despierta un proceso, pero como no puede haber más de un proceso en el Monitor, según la política que se tome, se debe poner a algún proceso en la cola de los que esperan por el Monitor pero como proceso parcialmente ejecutado. El problema viene cuando el proceso que salió, vuelve a entrar al Monitor y tiene las condiciones cambiadas, porque puede generar inconsistencias en su ejecución. Lo que se estila, es que el proceso que hace signal, lo haga en su última instrucción, luego de que haya terminado su ejecución, quedando en el Monitor el que acaba de despertarse. El que hizo signal, no vuelve a la cola de los que esperan por el Monitor.
Comparación con la solución con semáforos:
La estructura del semáforo está conformada por una cola y el valor asociado a las variables de condición. En el caso de los monitores, la estructura se simplicfica, porque sólo consta de una cola de procesos.
Ventajas respecto a estructuras de bajo nivel:
• Exclusión mútua automática.
• Construcción de alto nivel  Modularidad.
• Abstracción de datos.
Desventajas:
• Dos estructuras iguales compartidas por procesos diferentes requieren definir dos monitores diferentes.
• Llamadas anidadas (dentro de un Monitor, se puede definir otro Monitor, que a su vez puede conducir a situaciones de Deadlock).
M1
Procedimiento X
{
M2 Procedimiento Y
{wait()} ­­> A
Procedimiento Z
{signal()}
} Si se bloquea el proceso A, hace un llamada a M1, y M1 una llamada a M2, y M2 hace un wait, como consecuencia se libera el M2 pero no el M1.
• Especificar sincronización a través de las variables de condición.
EJEMPLO DE UN MONITOR PARA UN RECURSO:
Allocator = Monitor var busy = boolean;
free = condition;
procedure RESERVE()
if busy then wait(free);
busy := true;
end;
procedure RELEASE()
busy := false;
signal(free);
end;
begin
busy = false;
end.
Proceso (i)
. . .
Allocator.RESERVE;
USA RECURSO;
Allocator.RELEASE;
. . .
end.
żCÓMO DEFINIR UN MONITOR PARA n RECURSOS?
Allocator = Monitor Var free = condition;
var recursos = integer;
Procedure RESERVE()
if recursos >= 0 then wait(free);
recursos ­­;
end;
procedure RELEASE()
recursos ++;
if recursos = 1 then signal(free);
end; /*sólo se pudieron encolar procesos si no había recursos */
begin
recursos = n;
end;
PRODUCTOR/CONSUMIDOR:
M_Consumidor_Prod = Monitor;
var B = array [0..(n­1)] of integer;
in, out, count = integer;
/* count es la cantidad de datos dentro del buffer */
not_full, not_empty = condition;
procedure APPEND (var i:integer)
if count = n then wait(not_full);
B(in) := i;
in := (in + 1) mod n;
count := count + 1;
if count = 1 then signal(not_empty);
end. procedure TAKE (var i:integer)
if count = 0 then wait(not_empty);
i := B(out);
out := (out + 1) mod n;
count := count ­ 1;
if count = (n­1) then signal(not_full);
end. begin
in := 0;
out := 0;
count := 0;
end Monitor.
procedure PRODUCTOR (i)
. . .
produce_item;
M_Consumidor_Prod.APPEND(item);
. . .
end;
procedure CONSUMIDOR (i)
. . .
M_Consumidor_Prod.TAKE(item);
consume_item;
. . .
end;
Comparación con la solución por Semáforos:
Si son varios productore y consumidores, con semáforos teníamos problemas con “in” y “out”, ahora, como están definidos dentro del Monitor, tienen exclusión mútua automática. La implementación anterior sirve para todos los casos de productor/consumidor ( 1­1, n­n, n­m, etc.).
El problema que surge con Monitores, es que dos consumidores (o productores) no pueden acceder el buffer simultáneamente, en el caso de semáforos sí se podía.
LECTORES/ESCRITORES:
• Caso con prioridad para Lectores:
M_R_E = Monitor;
var readers = integer;
writing = boolean;
OK_to_read, OK_to_write = condition;
procedure START_READ()
if writing then wait(OK_to_read);
readers := readers + 1;
signal(OK_to_read);
end. procedure END_READ()
readers := readers ­ 1;
if readers = 0 then signal(OK_to_write);
end. procedure START_WRITE()
if readers ≠ 0 or writing then wait(OK_to_write);
writing = true;
end;
procedure END_WRITE()
writing = false;
if NOT_EMPTY(OK_to_read) then signal(OK_to_read)
else signal(OK_to_write);
end;
begin
readers = 0;
writing = false;
end_Monitor.
procedure READER (i)
. . .
START_READ;
READ;
END_READ;
. . .
end;
procedure WRITER (i)
. . .
START_WRITE;
WRITE;
END_WRITE;
. . .
end;
begin
parbegin
readers
writers
parend
end. • Caso con prioridad para Escritores: TAREA !!!!
FILÓSOFOS COMENSALES: (Para cinco filósofos)
Fork_Monitor = Monitor;
var Fork = array[0..4] of integer;
OK_to_eat = array[0..4] of condition;
j = integer;
procedure TAKE_FORK(var i:integer)
if Fork[i] ≠ 2 then waitc(OK_to_eat[i]);
Fork[(i+1) mod 5]:= Fork[(i+1) mod 5] ­ 1;
Fork[(i­1) mod 5]:= Fork[(i­1) mod 5] ­ 1;
end;
procedure RELEASE_FORK(var i:integer)
Fork[(i+1) mod 5]:= Fork[(i+1) mod 5] + 1;
Fork[(i­1) mod 5]:= Fork[(i­1) mod 5] + 1;
if Fork[i] = 2 then signal(OK_to_eat[(i+1) mod 5]);
if Fork[(i­1) mod 5] = 2 then
signal(OK_to_eat[(i­1) mod 5]);
end;
begin
for j := 0 to 5
Fork[j] := 2;
end_Monitor.
procedure PHILOSOPHER (i)
loop
think;
TAKE_FORK(i);
EAT;
RELEASE_FORK(i);
end_loop;
end;
PUEDE CAUSAR STARVATION !!!!
BARBERO DORMILÓN:
Si quiero generalizar, no puedo poner el corte de pelo en el Monitor.
TAREA !!!!!