monitores

INSTITUTO TECNOLOGICO de Morelia Sistemas Operativos

M. en C. Felipe Morales López 1 de 6

UNIDAD 5 MONITORES

5.1 Introducción Los semáforos son primitivas con las cuales es difícil expresar una solución a grandes problemas de concurrencia y su presencia en programas concurrentes incrementa la ya existente dificultad para probar que los programas son correctos. Los algoritmos para la implementación de la exclusión mutua basada en semáforos tienen algunas debilidades:

• La omisión de una de estas primitivas puede corromper la operación de un sistema concurrente.

• El control de la concurrencia es responsabilidad del programador. • Las primitivas de control se encuentran esparcidas por todo el sistema.

La noción de un monitor fue presentada inicialmente por Dijkstra (1971), posteriormente por Brinch Hansen (1973) y después fue refinada por Hoare (1974). 5. 2 Definición Un monitor es un mecanismo de software para control de concurrencia que contiene los datos y los procedimientos necesarios para realizar la asignación de un determinado recurso o grupo de recursos compartidos reutilizables en serie. • Un monitor se usa para manejar todas las funciones de concurrencia, comunicación entre

procesos y localización física de recursos en una región crítica. • Para llevar a cabo la asignación de un recurso un proceso debe llamar a una función particular

del monitor. Pueden existir varios procesos que deseen entrar al monitor, pero la exclusión mutua queda definida por la frontera del monitor: en un tiempo dado sólo un proceso se encuentra dentro del monitor.

• Los datos contenidos en el monitor pueden ser globales (accesibles a todos los procedimientos dentro del monitor), o locales (accesibles a un procedimiento específico). Estos datos sólo son accesibles dentro del monitor; no hay forma de que un proceso fuera del monitor pueda acceder a dichos datos.

• El monitor consta de varios procedimientos que manipulan datos internos y existe una parte de inicialización (figura 5.1). El monitor puede ser visto como una aduana en donde se permite o no el acceso a un recurso compartido.

• El código del monitor consta de 2 partes lógicas: • El algoritmo para la manipulación del recurso. • El mecanismo para la asignación del orden en el cual los procesos asociados pueden

compartir el recurso.


M. en C. Felipe Morales López

Figura

Para asegurar que un proceso obtengadarle prioridad sobre los nuevos prnuevos procesos tomaran el recurso aproceso que espera a la postergación • Dado que un proceso puede nec

mecanismo llamado variable de operaciones:

• wait(variable) Forma el p• signal(variable) Libera

operación implica la salid • Normalmente se usa una variable

de esperar. Si el proceso que se encuentra dendisponible, el procedimiento del monfuera del monitor (wait). El procesocondición de exclusión mutua y denecesita. Cuando el recurso se liberentrar.

Declaración Variables Globales

Procedimiento UNOVariables Locales

S
Procedimiento DO
2 de 6

5.1 Estructura básica de un monitor.

el recurso que espera, el monitor (la lógica del monitor) debe ocesos que solicitan entrar al monitor. De otra manera, los ntes de que el proceso que espera lo haga, esto puede llevar al indefinida.

esitar esperar fuera del monitor por varias razones se creo un condición. Una variable de condición se controla con solo dos

roceso en la lista de espera de la variable de condición. al primer proceso de la lista de la variable de decisión. Esta a del proceso actual del monitor.

de condición por cada situación por la cual un proceso debe

tro del monitor encuentra que el recurso que ocupa no está itor debe sacar momentáneamente al proceso y hacerlo esperar NO puede permanecer en el monitor ya que esto viola la be esperar fuera del monitor la liberación del recurso que

a se debe indicar que está libre para que otro proceso pueda

Procedimiento de inicialización



5.3 Diagrama de estados del Monitor En el estado activo existen tres opciones para que un proceso abandone el monitor:

1- SALIR: en este caso un proceso llega al final del procedimiento de monitor que está ejecutando. Por ejemplo, en la salida normal de una región crítica

2- CONTINUAR: Esta operación se realiza cuando el proceso activo completó una acción que otro proceso pudiera estar esperando (en el estado bloqueado) y entonces le envía la señal (signal) de que puede continuar. Al proceso bloqueado se le permite regresar a activo. Si no hay procesos bloqueados se abre la entrada del monitor.

3- RETARDAR: El retardo se presenta cuando un proceso necesita el resultado de una acción que otro proceso aún no realiza y entonces espera (wait).

El proceso que desbloquea a otro a través de la operación continuar debe dejar el monitor. 5.4 Ejemplos de aplicación de monitores Productor/consumidor con un buffer circular. Los sistemas operativos conceden algunas veces una cantidad fija de memoria para las comunicaciones a través del buffer entre los procesos consumidor y productor. Esto se puede simular por un arreglo de tamaño fijo. El productor deposita los datos en los elementos sucesivos del arreglo. El consumidor los quita en el orden que fueron depositados. El productor puede ir varios pasos adelante del consumidor. El productor llenará el último elemento del arreglo. Cuando produce más datos, tiene que regresar y continuar a depositar de nuevo datos en el primer elemento del arreglo (suponiendo que el consumidor haya retirado los datos previamente depositados allí por el productor), de esta forma, el arreglo se cierra en circulo. El buffer circular es apropiado para implementar el control del spool en los sistemas operativos.

Salir o Retardar o Continuar (2)

Continuar (1)

SALIR

CONTINUAR

RETARDAR

BLOQUEADO

ACTIVO ESPERA

Transiciones propias Transiciones forzadas



monitor ProductorConsumidor condition full, empty; integer count; procedure enter; begin if count = N then wait(full); enter_item; count:= count + 1; if count = 1 then signal(empty); end; procedure remove; begin if count = 0 then wait(empty); remove_item; count:= count - 1; if count = N - 1 then signal(full); end; count:= 0; end monitor;

procedure productor; begin while true do begin produce_item; ProductorConsumidor.enter; end end; procedure consumidor; begin while true do begin ProductorConsumidor.remove; consume_item; end end; begin parbegin productor; consumidor; parend end

Algoritmo 5.1 Productor/Consumidor implementado con un monitor module MonitorBufferCircular; var bufferCircular: array[0..Ranuras-1] of cosas; ranuraEnUso : [0..Ranuras]; RanuraAllenar: [0..Ranuras-1]; RanuraAvaciar: [0..Ranuras-1]; BCircularTieneDatos, BCircularTieneEspacio:condition; procedure llenarRanura(datosRanura:cosas); begin if ranuraEnUso = ranuras then wait(BCircularTieneEspacio); end; bufferCircular[RanuraAllenar]:=datosRanura; inc(ranuraEnUso); RanuraAllenar:= (RanuraAllenar+1) mod ranuras; signal(BCircularTieneDatos); end llenaRanura;

procedure vaciaRanura; begin if ranuraEnUso = 0 then wait(BCircularTieneDatos); end; datosRanura:=bufferCircular[RanuraAvaciar]; dec(ranuraEnUso); RanuraAvaciar:=(RanuraAvaciar+1) mod ranuras; signal(BCircularTieneEspacio); end vaciaRanura; begin ranuraEnUso:= 0; RanuraAllenar:= 0; RanuraAvaciar:= 0; end monitorBufferCircular

Algoritmo 5.2 Buffer circular implementado con un monitor.



Problema de los Lectores y Escritores. La solución de este problema se puede usar como un modelo para implementar un mecanismo de acceso a información compartida. Problema: Existen varios procesos lectores y escritores que acceden una base de datos común, las reglas de acceso son:

1- Cualquier número de procesos lectores puede acceder la base de datos en forma concurrente.

2- Cuando un proceso escritor está accediendo la base de datos ningún otro proceso, ni lector, ni escritor podrá accederla.

3- Cuando están accediendo procesos lectores y se tenga por lo menos a un escritor esperando acceso, los lectores que llegaron después del escritor no acceden directamente sino esperan.

4- Los procesos lectores esperando que un escritor termine su acceso tienen prioridad sobre el siguiente escritor.

5- Un escritor esperando que los procesos lectores terminen su acceso tiene prioridad sobre los lectores que están esperando.

module MLecEsc; var lectores: integer; AlguienEstaEscribiendo : boolean; LecturaPermitida, EscrituraPermitida: condition; procedure ComienzaLectura; begin if AlguienEstaEscribiendo or queue(EscrituraPermitida) then wait(LecturaPermitida); end: inc(lectores); signal(LecturaPermitida); end ComienzaLectura; procedure TerminaLectura; begin dec(lectores); if lectores = 0 then signal(EscrituraPermitida); end; end TerminaLectura;

procedure ComienzaEscritura; begin if (lectores > 0) or (AlguienEstaEscribiendo) then wait(EscrituraPermitida); end; AlguienEstaEscribiendo:=true; end ComienzaEscritura; procedure TerminaEscritura; begin AlguienEstaEscribiendo:=false; if queue(LecturaPermitida) then signal(LecturaPermitida); else signal(EscrituraPermitida); end; end TerminaEscritura; begin lectores:=0; AlguienEstaEscribiendo:=false; end.

Algoritmo 5.3 Problema de los Lectores y Escritores. Problema de los Filósofos. Existen n filósofos que pasan su vida pensando y comiendo. • Cada filósofo tiene su lugar en una mesa circular en cuyo centro está un plato con espagueti. • Para comer espagueti se requieren dos tenedores, pero sólo hay n tenedores, uno entre cada par

de filósofos. • Los únicos tenedores que puede tomar un filósofo son los inmediatos a su izquierda y derecha.



El problema es simular el comportamiento de un filósofo igual para todos, de tal forma que: • Se evite el interbloqueo, por ejemplo, cuando simultáneamente cada filósofo toma su tenedor

izquierdo y se queda esperando por su tenedor derecho. • Se evite la inanición esto es, que un filósofo no pueda comer y se muera de hambre. 5.5 Implementación de monitores con Java El siguiente ejemplo es una implementación del problema productor/consumidor con java. Se compone de cuatro clases simples: Q, la cola cuyo acceso se trata de sincronizar; Producer, el objeto hilo que genera datos para la cola; Consumer, el objeto hilo que consume datos de la cola; y, PC, la miniclase que crea Q, Producer y Consumer. class Q { int n; boolean valueSet = false; synchronized int get( ) { if (!valueSet) try wait( ); catch(InterruptedException e); System.out.println (“Obtenido: “ + n); valueSet = false; notify( ); return n; } synchronized int put(int n) { if (valueSet) try wait( ); catch(InterruptedException e); this.n = n; valueSet = true; System.out.println (“Colocado: “ + n); notify( ); } } class Producer implements Runnable { Q q; Producer (Q q) { this.q = q; new Thread(this, “Producer”).start( ); } public void run( ) { int i = 0; while(true) { q.put( i++ ); } } }

class Consumer implements Runnable { Q q; Producer (Q q) { this.q = q; new Thread(this, “Consumer”).start( ); } public void run( ) { while(true) { q.get( ); } } } class PC { public static void main(String args[ ] ) { Q q = new Q( ); new Producer (q); new Consumer(q); } }

monitores

Documents