INSTITUTO TECNOLOGICO de Morelia

Sistemas Operativos

UNIDAD 5
MONITORES
5.1 Introduccin Los semforos son primitivas con las cuales es difcil expresar una solucin 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 implementacin de la exclusin mutua basada en semforos tienen algunas debilidades: La omisin de una de estas primitivas puede corromper la operacin 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 nocin de un monitor fue presentada inicialmente por Dijkstra (1971), posteriormente por Brinch Hansen (1973) y despus fue refinada por Hoare (1974).

5. 2 Definicin Un monitor es un mecanismo de software para control de concurrencia que contiene los datos y los procedimientos necesarios para realizar la asignacin de un determinado recurso o grupo de recursos compartidos reutilizables en serie. Un monitor se usa para manejar todas las funciones de concurrencia, comunicacin entre procesos y localizacin fsica de recursos en una regin crtica. Para llevar a cabo la asignacin de un recurso un proceso debe llamar a una funcin particular del monitor. Pueden existir varios procesos que deseen entrar al monitor, pero la exclusin mutua queda definida por la frontera del monitor: en un tiempo dado slo 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 especfico). Estos datos slo 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 inicializacin (figura 5.1). El monitor puede ser visto como una aduana en donde se permite o no el acceso a un recurso compartido. El cdigo del monitor consta de 2 partes lgicas: El algoritmo para la manipulacin del recurso. El mecanismo para la asignacin del orden en el cual los procesos asociados pueden compartir el recurso.

M. en C. Felipe Morales Lpez

1 de 6

INSTITUTO TECNOLOGICO de Morelia

Sistemas Operativos

Declaracin Variables Globales Procedimiento UNO Variables Locales

Procedimiento DOS

Procedimiento de inicializacin

Figura 5.1 Estructura bsica de un monitor.

Para asegurar que un proceso obtenga el recurso que espera, el monitor (la lgica del monitor) debe darle prioridad sobre los nuevos procesos que solicitan entrar al monitor. De otra manera, los nuevos procesos tomaran el recurso antes de que el proceso que espera lo haga, esto puede llevar al proceso que espera a la postergacin indefinida. Dado que un proceso puede necesitar esperar fuera del monitor por varias razones se creo un mecanismo llamado variable de condicin. Una variable de condicin se controla con solo dos operaciones: wait(variable) Forma el proceso en la lista de espera de la variable de condicin. signal(variable) Libera al primer proceso de la lista de la variable de decisin. Esta operacin implica la salida del proceso actual del monitor.

Normalmente se usa una variable de condicin por cada situacin por la cual un proceso debe de esperar.

Si el proceso que se encuentra dentro del monitor encuentra que el recurso que ocupa no est disponible, el procedimiento del monitor debe sacar momentneamente al proceso y hacerlo esperar fuera del monitor (wait). El proceso NO puede permanecer en el monitor ya que esto viola la condicin de exclusin mutua y debe esperar fuera del monitor la liberacin del recurso que necesita. Cuando el recurso se libera se debe indicar que est libre para que otro proceso pueda entrar.

M. en C. Felipe Morales Lpez

2 de 6

INSTITUTO TECNOLOGICO de Morelia

Sistemas Operativos

5.3 Diagrama de estados del Monitor

Salir o Retardar o ESPERA Continuar (2) ACTIVO Continuar (1) Transiciones propias BLOQUEADO Transiciones forzadas

SALIR

CONTINUAR

RETARDAR

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 regin crtica 2- CONTINUAR: Esta operacin se realiza cuando el proceso activo complet una accin que otro proceso pudiera estar esperando (en el estado bloqueado) y entonces le enva la seal (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 accin que otro proceso an no realiza y entonces espera (wait). El proceso que desbloquea a otro a travs de la operacin continuar debe dejar el monitor.

5.4 Ejemplos de aplicacin de monitores Productor/consumidor con un buffer circular. Los sistemas operativos conceden algunas veces una cantidad fija de memoria para las comunicaciones a travs del buffer entre los procesos consumidor y productor. Esto se puede simular por un arreglo de tamao 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 ms 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.

M. en C. Felipe Morales Lpez

3 de 6

INSTITUTO TECNOLOGICO de Morelia

Sistemas Operativos

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.

M. en C. Felipe Morales Lpez

4 de 6

INSTITUTO TECNOLOGICO de Morelia

Sistemas Operativos

Problema de los Lectores y Escritores. La solucin de este problema se puede usar como un modelo para implementar un mecanismo de acceso a informacin compartida. Problema: Existen varios procesos lectores y escritores que acceden una base de datos comn, las reglas de acceso son: 123Cualquier nmero de procesos lectores puede acceder la base de datos en forma concurrente. Cuando un proceso escritor est accediendo la base de datos ningn otro proceso, ni lector, ni escritor podr accederla. Cuando estn accediendo procesos lectores y se tenga por lo menos a un escritor esperando acceso, los lectores que llegaron despus del escritor no acceden directamente sino esperan. Los procesos lectores esperando que un escritor termine su acceso tienen prioridad sobre el siguiente escritor. Un escritor esperando que los procesos lectores terminen su acceso tiene prioridad sobre los lectores que estn esperando.
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.

45-

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;

Problema de los Filsofos. Existen n filsofos que pasan su vida pensando y comiendo. Cada filsofo tiene su lugar en una mesa circular en cuyo centro est un plato con espagueti. Para comer espagueti se requieren dos tenedores, pero slo hay n tenedores, uno entre cada par de filsofos. Los nicos tenedores que puede tomar un filsofo son los inmediatos a su izquierda y derecha.
M. en C. Felipe Morales Lpez

5 de 6

INSTITUTO TECNOLOGICO de Morelia

Sistemas Operativos

El problema es simular el comportamiento de un filsofo igual para todos, de tal forma que: Se evite el interbloqueo, por ejemplo, cuando simultneamente cada filsofo toma su tenedor izquierdo y se queda esperando por su tenedor derecho. Se evite la inanicin esto es, que un filsofo no pueda comer y se muera de hambre. 5.5 Implementacin de monitores con Java El siguiente ejemplo es una implementacin 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); } }

M. en C. Felipe Morales Lpez

6 de 6