Site hosted by Angelfire.com: Build your free website today!
     
 



Administrador de Procesos y del Procesador

2.4.2.2 Mecanismos de Monitoreo

    

Aunque los semaforos proporcionan un mecanismo adecuado y efectivo para el proceso de sin-cronizacion, un uso incorrecto de los mismos puede dar lugar a errores de temporizacion que son dificiles de detectar, dado que estos errores solo ocurren si tienen lugar algunas secuencias de eje-cucion concretas y estas secuencias no siempre se producen.

Hemos visto un ejemplo de dichos errores en el uso de contadores en la solucion del problema productor-consumidor (Seccion 6.1). En ese ejemplo, el problema de temporizacion se producia raras veces, e incluso entonces el valor del contador parecia ser razonable: lo que pasaba es que diferia en 1 del valor correcto. Pero aunque el valor pareciera correcto, no era aceptable y es por esta razon que se introdujeron los semaforos.

Lamentablemente, estos errores de temporizacion pueden producirse tambien cuando se emplean semaforos. Para ilustrar como, revisemos la solucion con semaforos para el problema de la seccion critica. Todos los procesos comparten una variable de semaforo mutex, que se iniciali-za con el valor 1. Cada proceso debe ejecutar una operacion wait (mutex) antes de entrar en la seccion critica y una operacion signal (mutex) despues de la misma. Si esta secuencia no se lleva a cabo, dos procesos podrian estar dentro de sus secciones criticas al mismo tiempo. Examinemos los problemas a los que esto da lugar. Observe que estos problemas surgiran inclu-so aunque solo sea un unico proceso el que no se comporte de la forma adecuada; dicha situacion puede deberse a un error de programacion no intencionado o a que un cierto programador no tenga muchas ganas de cooperar.

Suponga que un proceso intercambia el ordenen el que se ejecutan las operaciones wait() y signal (), dando lugar a la siguiente secuencia de ejecucion:

signal(mutex);
seccion critica
wait(mutex);

En esta situacion, varios procesos pueden estar ejecutando sus secciones criticas simultane-amente, violando el requisito de exclusion mutua. Observe que este error solo puede des-cubrirse si varios procesos estan activos simultaneamente en sus secciones criticas y que esta situacion no siempre se produce.

???? Suponga que un proceso reemplaza signal(mutex) por wait(mutex). Es decir, ejecuta

wait(mutex);

seccion critica wait(mutex);

En este caso, se producira un interbloqueo.

  •     Suponga que un proceso omite la operacion wait( mutex ), la operacion signal (mutex) , o ambas. En este caso, se violara la exclusion mutua o se producira un interbloqueo.

Estos ejemplos ilustran los distintos tipos de error que se pueden generar facilmente cuando los programadores emplean incorrectamente los semaforos para solucionar el problema de la seccion critica..

Para abordar tales errores, los investigadores han desarrollado estructuras de lenguaje de alto nivel. En esta seccion, vamos a describir una estructura fundamental de sincronizacion de alto nivel, el tipo monitor.

    Utilizacion

Un tipo, o un tipo abstracto de datos, agrupa una serie de datos privados con un conjunto de metodos publicos que se utilizan para operar sobre dichos datos. Un tipo monitor tiene un con-junto de operaciones definidas por el programador que gozan de la caracteristica de exclusion mutua dentro del monitor. El tipo monitor tambien contiene la declaracion de una serie de variables cuyos valores definen el estado de una instancia de dicho tipo, junto con los cuerpos de los procedimientos o funciones que operan sobre dichas variables. En la Figura 6.16 se muestra la sin-taxis de un monitor. La representacion de un tipo monitor no puede ser utilizada directamente por los diversos procesos. Asi, un procedimiento definido dentro de un monitor solo puede acceder a las variables declaradas localmente dentro del monitor y a sus parametros formales. De forma similar, a las variables locales de un monitor solo pueden acceder los procedimientos locales.

La estructura del monitor asegura que solo un proceso este activo cada vez dentro del monitor. En consecuencia, el programador no tiene que codificar explicitamente esta restriccion de sincronizacion. Sin embargo, la estructura de monitor, como se ha definido hasta ahora, no es lo suficientemente potente como para modelar algunos esquemas de sincronizacion. Para ello, necesitamos definir mecanismos de sincronizacion adicionales. Estos mecanismos los proporciona la estructura condition. Un programador que necesite escribir un esquema de sincronizacion a medida puede definir una o mas variables de tipo condition:

    condition x, y;

Las unicas operaciones que se pueden invocar en una variable de condicion son wait () y signal () . La operacion

x.wait();

indica que el proceso que invoca esta operacion queda suspendido hasta que otro proceso invo-que la operacion

x.signal();

La operacion x.signal() hace que se reanude exactamente uno de los procesos suspendidos. Si no habia ningun proceso suspendido, entonces la operacion signal () no tiene efecto, es decir, el estado de x sera el mismo que si la operacion nunca se hubiera ejecutado Compare esta operacion con la operacion signal () asociada con los semaforos, que siempre afectaba al estado del semaforo.

Suponga ahora que, cuando un proceso invoca la operacion x. signal(), hay un proceso en estado suspendido asociado con la condicion x. Evidentemente, si se permite al proceso sus-pendido Q reanudar su ejecucion, el proceso P que ha efectuado la senalizacion debera esperar; en caso contrario, P y Q se activarian simultaneamente dentro del monitor. Sin embargo, observe que conceptualmente ambos procesos pueden continuar con su ejecucion. Existen dos posibilidades:

1. Senalizar y esperar. P espera hasta que Q salga del monitor o espere a que se produzca otra condicion.
2. Senalizar y continuar. Q espera hasta que P salga del monitor o espere a que se produzca otra condicion.

Hay argumentos razonables en favor de adoptar cualquiera de estas opciones. Por un lado, puesto que P ya estaba ejecutandose en el monitor, el metodo de senalizar y continuar parece el mas razonable. Por otro lado, si permitimos que la hebra P continue, para cuando se reanude la ejecu-cion de Q, es posible que ya no se cumpla la condicion logica por la que Q estaba esperando. En el lenguaje Pascal Concurrente se adopto un compromiso entre estas dos opciones: cuando la hebra P ejecuta la operacion signal, sale inmediatamente del monitor. Por tanto, la ejecucion de Q se reanuda de forma inmediata.

monitor nombre del monitor {
// declaraciones de variables compartidas procedimiento P1 ( . . . )?????????????????????????????????????????????????????????? {

}
procedimiento P2 (??????????????? . . )???????? {

}
procedimiento Pn ( .????????????????????? )????? {

}
codigo de inicializacion ( .???? )?????????? {
}
}

2.4.1 Exclusion mutua de Seccion Critica 2.4.2 Sincronizacion de Procesos 2.4.2.1 Mecanismos de Semaforos 2.4.2.2 Mecanismos de Monitoreo 2.4.3 Interbloqueo Evaluacion ->Regresar al Indice