INTRODUCCIN El algoritmo de Drekker es un algoritmo de programacin concurrente para exclusin mutua, que permite a dos procesos o hilos de ejecucin

compartir un recurso sin co nflictos. Fue uno de los primeros algoritmos de exclusin mutua inventados, implem entado por Edsger Dijkstra. Si ambos procesos intentan acceder a la seccin crtica simultneamente, el algoritmo elige un proceso segn una variable turno. Si el otro proceso est ejecutando en su seccin crtica, deber esperar su finalizacin. En los sistemas operativos multiprogramados surge el concepto de proceso, asoci ado a la ejecucin de un programa. En general, un proceso es un flujo de ejecucin, representado bsicamente por un contador de programa, y su contexto de ejecucin, qu e puede ser ms o menos amplio. As, un proceso incluye en su contexto el estado de la pila, el estado de la memoria y el estado de la E/S, mientras que un thread tp ico tiene como contexto propio poco ms que la pila. En algunos sistemas es posibl e determinar el contexto propio de un proceso en el momento de su creacin, como o curre con la llamada al sistema clone() de Linux. En adelante, sin perder genera lidad, utilizaremos siempre el trmino proceso, independientemente de cul sea su co ntexto. Uno de los objetivos del sistema operativo es la representacin de los procesos y el soporte de los cambios de contexto entre procesos, que posibilitan la compar ticin del recurso CPU. El acceso a otros recursos compartidos y la comunicacinentr e procesos relacionados (por ejemplo, de una misma aplicacin) hacen necesaria la utilizacin de mecanismos de sincronizacin dentro del sistema operativo. Tpicamente, un proceso requiere la CPU durante un periodo de tiempo, realiza alguna operacin de E/S, y vuelve a requerir la CPU, repitindose este ciclo hasta la finalizacin d el programa. El proceso pasa por diversos estados entre los que se definen trans iciones, como representa, en su forma ms sencilla, el grafo de la Figura siguient e. Cada vez que un proceso pasa al estado preparado, est compitiendo por el recurso CPU. Un segundo objetivo del sistema operativo multiprogramado es la planificac in del uso del (de los) recurso(s) de proceso. Los criterios que se siguen para l a planificacin y las polticas que se usan se estudiarn mas adelante en el desarroll o de la presente investigacin. PROCESAMIENTO PARALELO Las arquitecturas paralelas tienen un notable incremento en la velocidad de pro cesamiento.

En computacin, el procesamiento paralelo es la ejecucin de diferentes procesos en dos o mas procesadores al mismo tiempo, donde estos procesos juntos resuelven u n problema completamente. Un proceso debe entenderse como un fragmento de cdigo en ejecucin que convive con otros fragmentos. El procesamiento paralelo ofrece una gran ventaja en cuanto a costos. Sin embar go, su principal beneficio, la escalabilidad (crecer hacia arquitecturas de mayo r capacidad), puede ser difcil de alcanzar an. Esto se debe a que conforme se aaden procesadores, las disputas por los recursos compartidos se intensifican. Algunos diseos diferentes de procesamiento paralelo enfrentan este problema funda mental:

Multiprocesamiento simtrico Procesamiento masivamente paralelo Procesamiento paralelo escalable Cada diseo tiene sus propias ventajas y desventajas.

El Multiprocesamiento simtrico (symmetric multiprocessing / SMP) tiene un diseo s imple pero an as efectivo. En SMP, mltiples procesadores comparten la memoria RAM y el bus del sistema. Este diseo es tambin conocido como estrechamente acoplado (ti ghtly coupled), o compartiendo todo (shared everything). Debido a que SMP comparte globalmente la memoria RAM, tiene solamente un espaci o de memoria, lo que simplifica tanto el sistema fsico como la programacin de apli caciones. Este espacio de memoria nico permite que un Sistema Operativo con Multi conexin (multithreaded operating system) distribuya las tareas entre varios proce sadores, o permite que una aplicacin obtenga la memoria que necesita para una sim ulacin compleja. La memoria globalmente compartida tambin vuelve fcil la sincroniza cin de los datos. SMP es uno de los diseos de procesamiento paralelo ms maduro. Apareci en los super computadores Cray X-MP y en sistemas similares hace dcada y media (en 1983). Sin embargo, esta memoria global contribuye el problema ms grande de SMP: confor me se aaden procesadores, el trfico en el bus de memoria se satura. Al aadir memori a cach a cada procesador se puede reducir algo del trfico en el bus, pero el bus g eneralmente se convierte en un cuello de botella al manejarse alrededor de ocho o ms procesadores. SMP es considerada una tecnologa no escalable.

El Procesamiento masivamente paralelo (Massively parallel processing / MPP) es otro diseo de procesamiento paralelo. Para evitar los cuellos de botella en el bu s de memoria, MPP no utiliza memoria compartida. En su lugar, distribuye la memo ria RAM entre los procesadores de modo que se semeja a una red (cada procesador con su memoria distribuida asociada es similar a un computador dentro de una red de procesamiento distribuido). Debido a la distribucin dispersa de los recursos RAM, esta arquitectura es tambin conocida como dispersamente acoplada (loosely co upled), o compartiendo nada (shared nothing). Para tener acceso a la memoria fuera de su propia RAM, los procesadores utiliza n un esquema de paso de mensajes anlogo a los paquetes de datos en redes. Este si stema reduce el trfico del bus, debido a que cada seccin de memoria observa nicamen te aquellos accesos que le estn destinados, en lugar de observar todos los acceso s, como ocurre en un sistema SMP. nicamente cuando un procesador no dispone de la memoria RAM suficiente, utiliza la memoria RAM sobrante de los otros procesador es. Esto permite sistemas MPP de gran tamao con cientos y an miles de procesadores . MPP es una tecnologa escalable. El RS/6000 Scalable Powerparallel System de IBM (SP2) es un ejemplo de sistema MPP, que presenta una ligera variante respecto al esquema genrico anteriormente p lanteado. Los procesadores del RS/6000 se agrupan en nodos de 8 procesadores, lo s que utilizan una nica memoria compartida (tecnologa SMP). A su vez estos nodos s e agrupan entre s utilizando memoria distribuida para cada nodo (tecnologa MPP). D e este modo se consigue un diseo ms econmico y con mayor capacidad de crecimiento.

La parte negativa de MPP es que la programacin se vuelve difcil, debido a que la

memoria se rompe en pequeos espacios separados. Sin la existencia de un espacio d e memoria globalmente compartido, correr (y escribir) una aplicacin que requiere una gran cantidad de RAM (comparada con la memoria local), puede ser difcil. La s incronizacin de datos entre tareas ampliamente distribuidas tambin se vuelve difcil , particularmente si un mensaje debe pasar por muchas fases hasta alcanzar la me moria del procesador destino. Escribir una aplicacin MPP tambin requiere estar al tanto de la organizacin de la memoria manejada por el programa. Donde sea necesario, se requieren insertar comandos de paso de mensajes dentro del cdigo del programa. Adems de complicar el diseo del programa, tales comandos pu eden crear dependencias de hardware en las aplicaciones. Sin embargo, la mayor p arte de vendedores de computadores han salvaguardado la portabilidad de las apli caciones adoptando, sea un mecanismo de dominio pblico para paso de mensajes cono cido como Mquina virtual paralela (parallel virtual machine / PVM), o un estndar e n fase de desarrollo llamado Interfaz de Paso de Mensajes (Message Passing Inter face / MPI), para implementar el mecanismo de paso de mensajes.

Cmo superar las dificultades de SMP y MPP? La ltima arquitectura paralela, el Proc esamiento paralelo escalable (Scalable parallel processing / SPP), es un hbrido d e SMP y MPP, que utiliza una memoria jerrquica de dos niveles para alcanzar la es calabilidad. La primera capa de memoria consiste de un nodo que es esencialmente un sistema SMP completo, con mltiples procesadores y su memoria globalmente comp artida. Se construyen sistemas SPP grandes interconectando dos o mas nodos a travs de la segunda capa de memoria, de modo que esta capa aparece lgicamente, ante los nodo s, como una memoria global compartida. La memoria de dos niveles reduce el trfico de bus debido a que solamente ocurren actualizaciones para mantener coherencia de memoria. Por tanto, SPP ofrece faci lidad de programacin del modelo SMP, a la vez que provee una escalabilidad simila r a la de un diseo MPP.

EXCLUSIN MUTUA Los algoritmos de exclusin mutua (comnmente abreviada como mutex por mutual exclu sion) se usan en programacin concurrente para evitar que fragmentos de cdigo conoc idos como secciones crticas accedan al mismo tiempo a recursos que no deben ser c ompartidos. La mayor parte de estos recursos son las seales, contadores, colas y otros datos que se emplean en la comunicacin entre el cdigo que se ejecuta cuando se da servi cio a una interrupcin y el cdigo que se ejecuta el resto del tiempo. Se trata de u n problema de vital importancia porque, si no se toman las precauciones debidas, una interrupcin puede ocurrir entre dos instrucciones cualesquiera del cdigo norm al y esto puede provocar graves fallos. La tcnica que se emplea por lo comn para conseguir la exclusin mutua es inhabilita r las interrupciones durante el conjunto de instrucciones ms pequeo que impedir la corrupcin de la estructura compartida (la seccin crtica). Esto impide que el cdigo d e la interrupcin se ejecute en mitad de la seccin crtica. En un sistema multiprocesador de memoria compartida, se usa la operacin indivisi

ble test-and-set sobre una bandera, para esperar hasta que el otro procesador la despeje. La operacin test-and-set realiza ambas operaciones sin liberar el bus d e memoria a otro procesador. As, cuando el cdigo deja la seccin crtica, se despeja l a bandera. Esto se conoce como spin lock o espera activa. Algunos sistemas tienen instrucciones multioperacin indivisibles similares a las anteriormente descritas para manipular las listas enlazadas que se utilizan par a las colas de eventos y otras estructuras de datos que los sistemas operativos usan comnmente. La mayora de los mtodos de exclusin mutua clsicos intentan reducir la latencia y es pera activa mediante las colas y cambios de contexto. Algunos investigadores afi rman que las pruebas indican que estos algoritmos especiales pierden ms tiempo de l que ahorran. A pesar de todo lo dicho, muchas tcnicas de exclusin mutua tienen efectos colater ales. Por ejemplo, los semforos permiten interbloqueos (deadlocks) en los que un proceso obtiene un semforo, otro proceso obtiene el semforo y ambos se quedan a la espera de que el otro proceso libere el semforo. Otros efectos comunes incluyen la inanicin, en el cual un proceso esencial no se ejecuta durante el tiempo desea do, y la inversin de prioridades, en el que una tarea de prioridad elevada espera por otra tarea de menor prioridad, as como la latencia alta en la que la respues ta a las interrupciones no es inmediata. La mayor parte de la investigacin actual en este campo, pretende eliminar los ef ectos anteriormente descritos. Si bien no hay un esquema perfecto conocido, hay un interesante esquema no clsico de envo de mensajes entre fragmentos de cdigo que, aunque permite inversiones de prioridad y produce una mayor latencia, impide lo s interbloqueos. Algunos ejemplos de algoritmos clsicos de exclusin mutua son: El algoritmo de Dekker. El algoritmo de Peterson. Cierre de exclusin mutua En ciencias de la computacin, los cierres de exclusin mutua son un mecanismo de s incronizacin que limita el acceso a un recurso compartido por varios procesos o h ilos en un ambiente de ejecucin concurrente, permitiendo as la exclusin mutua. Cuando un elemento es compartido por ms de un hilo, pueden ocurrir condiciones d e carrera si el mismo no es protegido adecuadamente. El mecanismo ms simple para la proteccin es el cierre o lock. En general cuando debe protegerse un conjunto d e elementos, se le asocia un lock. Cada proceso/hilo para tener acceso a un elem ento del conjunto, deber bloquear, con lo que se convierte en su dueo. Esa es la ni ca forma de ganar acceso. Al terminar de usarlo, el dueo debe desbloquear, para p ermitir que otro proceso/hilo pueda tomarlo a su vez. Es posible que mientras un proceso/hilo est accediendo a un recurso (siendo por lo tanto dueo del lock), otr o proceso/hilo intente acceder. Esta accin debe ser demorada hasta que el lock se encuentre libre, para garantizar la exclusin mutua. El proceso/hilo solicitante queda entonces en espera o pasa a estado de bloqueo segn el algoritmo implementad o. Cuando el dueo del lock lo desbloquea puede tomarlo alguno de los procesos/hil os que esperaban. Este mecanismo se puede ver en un ejemplo de la vida real. Supongamos un bao pbli co, donde slo puede entrar una persona a la vez. Una vez dentro, se emplea un cie rre para evitar que entren otras personas. Si otra persona pretende usar el bao c uando est ocupado, deber quedar esperando a que la persona que entr anteriormente t ermine. Si ms personas llegaran, formaran una cola (del tipo FIFO) y esperaran su t urno. En informtica, el programador no debe asumir este tipo de comportamiento en la cola de espera.

El lock, usado de esta manera, forma una seccin crtica en cada proceso/hilo, desd e que es tomado hasta que se libera. En el ejemplo del bao, dentro de la seccin crt ica se encuentran las funciones que se realizan generalmente dentro de este tipo de instalaciones sanitarias. Como garantizan la exclusin mutua, muchas veces se los denomina mutex (por mutual exclusion). En general hay un nmero de restricciones sobre los locks, aunque no son las misma s en todos los sistemas. Estas son: Slo el dueo de un lock puede desbloquearlo La readquisicin de un lock no est permitida Algo muy importante es que todos los procesos/hilos deben utilizar el mismo pro tocolo para bloquear y desbloquear los locks en el acceso a los recursos, ya que si mientras dos procesos/hilos utilizan el lock de forma correcta, existe otro que simplemente accede a los datos protegidos, no se garantiza la exclusin mutua y pueden darse condiciones de carrera y errores en los resultados. Primitivas y uso Las funciones de los locks en general son tres: init(), lock() y unlock(). El l ock se inicializa con la funcin init(). Luego cada proceso/hilo debe llamar a la funcin lock() antes de acceder a los datos protegidos por el cierre. Al finalizar su seccin crtica, el dueo del lock debe besbloquearlo mediante la funcin unlock(). ALGORITMO DE DEKKER El algoritmo de Dekker es un algoritmo de programacin concurrente para exclusin m utua, que permite a dos procesos o hilos de ejecucin compartir un recurso sin con flictos. Fue uno de los primeros algoritmos de exclusin mutua inventados, impleme ntado por Edsger Dijkstra. Si ambos procesos intentan acceder a la seccin crtica simultneamente, el algoritmo elige un proceso segn una variable turno. Si el otro proceso est ejecutando en su seccin crtica, deber esperar su finalizacin. Existen cinco versiones del algoritmo Dekker, teniendo ciertos fallos los prime ros cuatro. La versin 5 es la que trabaja ms eficientemente, siendo una combinacin de la 1 y la 4. Versin 1: Alternancia estricta. Garantiza la exclusin mutua, pero su desventaja e s que acopla los procesos fuertemente, esto significa que los procesos lentos at rasan a los procesos rpidos. Versin 2: Problema interbloqueo. No existe la alternancia, aunque ambos procesos caen a un mismo estado y nunca salen de ah. Versin 3: Colisin regin crtica no garantiza la exclusin mutua. Este algoritmo no evi ta que dos procesos puedan acceder al mismo tiempo a la regin critica. Versin 4: Postergacin indefinida. Aunque los procesos no estn en interbloqueo, un proceso o varios se quedan esperando a que suceda un evento que tal vez nunca su ceda. shared int cierto = 1; ''/* Definicin de variables compartidas */ '' shared int bandera[2] = {0,0}; shared int turno = 0; while (cierto) { bandera[proc_id] = cierto; while (bandera[1-proc_id] == cierto) {

if (turno == 1-proc_id) { bandera[proc_id] = 0; while (turno == (1-proc_id)) /* espera a que sea su turno de intentar */; bandera[proc_id] = 1; } } /* ''Seccin crtica'' */ turno = 1-proc_id; /* es el turno del otro proceso */ bandera[proc_id] = 0; /* ''Seccin no crtica'' */ } ALGORITMO DE PETERSON El algoritmo de Peterson es un algoritmo de programacin concurrente para exclusin mutua, que permite a dos o ms procesos o hilos de ejecucin compartir un recurso s in conflictos, utilizando slo memoria compartida para la comunicacin. Peterson desarroll el primer algoritmo (1981) para dos procesos que fue una simp lificacin del algoritmo de Dekker para dos procesos. Posteriormente este algoritm o fue generalizado para que funcione para N procesos. Algoritmo para dos procesos bandera[0] = 0 bandera[1] = 0 turno = 0 p0: bandera[0] = 1 p1: bandera[1] = 1 turno = 1 turno = 0 while( bandera[1] && turno == 1 ); while( bandera[0] && turno == 0 ); //no hace nada. espera. //no hace nada. espera. // seccin crtica // seccin crtica // fin de la seccin crtica // fin de la seccin crtica bandera[0] = 0 bandera[1] = 0 LA SINCRONIZACIN La sincronizacin se utiliza para regresar a un estado anterior conocido en caso de error durante la sesin. Aunque parezca innecesario (la capa de transporte slo r ecupera errores de comunicacin) ocurren muchos errores a nivel de sesiones entre usuarios (capas superiores). Si los datos se envan a un host remoto y ste imprime la informacin, un fallo en la impresin puede hacer que se pierda un mensaje ya confirmado al emisor. Si dividi mos el mensaje en pginas (puntos de sincronizacin) podemos confirmarlas y en su ca so retransmitirlas individualmente resincronizacin. Los usuarios pueden insertar puntos de sincronizacin (PdS) durante una sesin. Cad a PdS lleva un nmero identificativo. Cuando un extremo pide un PdS el otro recibe una indicacin. Igualmente cuando un extremo pide resincronizar el otro recibe un a indicacin.

En ningn caso se recupera el error a nivel de sesin. A este nivel se dan las prim itivas para poder resincronizar pero sta se debe llevar a cabo en niveles superio

res. Existen dos tipos de puntos de sincronizacin. Cada tipo de punto tiene su co njunto de primitivas asociadas. Dos puntos de sincronizacin mayor delimitan una U NIDAD DE DILOGO. SEMFORO Un semforo es una variable especial protegida (o tipo abstracto de datos) que co nstituye el mtodo clsico para restringir o permitir el acceso a recursos compartid os (por ejemplo, un recurso de almacenamiento del sistema o variables del cdigo f uente) en un entorno de multiprocesamiento (en el que se ejecutarn varios proceso s concurrentemente). Fueron inventados por Edsger Dijkstra y se usaron por prime ra vez en el sistema operativo THEOS. Operaciones Los semforos slo pueden ser manipulados usando las siguientes operaciones (este es el cdigo con espera activa): Inicia(Semforo s, Entero v) { s = v; } En el que se iniciar la variable semforo s a un valor entero v. P(Semforo s) { if(s>0) s = s-1; else wait(); } La cual mantendr en espera activa al regido por el semforo si este tiene un valor inferior o igual al nulo. V(Semforo s) { if(!procesos_bloqueados) s = s+1; else signal(); } Estas instrucciones pueden modificarse para evitar la espera activa, haciendo q ue la operacin P duerma al mismo proceso que la ejecuta si no puede decrementar e l valor, mientras que la operacin V despierta a un proceso que no es quien la eje cuta. En un pseudolenguaje ms entendible, la operacin P suele denominarse "wait" o "espera" y la operacin V "signal" o "seal". El por qu de los nombres de estas funciones, V y P, tienen su origen en el idiom a holands. "Verhogen" significa incrementar y "Proberen" probar, aunque Dijkstra us la palabra inventada prolaag [1], que es una combinacin de probeer te verlagen (intentar decrementar). El valor del semforo es el nmero de unidades del recurso q ue estn disponibles (si slo hay un recurso, se utiliza un "semforo binario" con los valores 0 y 1). Si hay n recursos, se inicializar el semforo al nmero n. As, cada proceso, al ir so licitando un recurso, verificar que el valor del semforo sea mayor de 0; si es as e s que existen recursos libres, seguidamente acaparar el recurso y decrementar el v alor del semforo. Cuando el semforo alcance el valor 0, significar que todos los recursos estn siend o utilizados, y los procesos que quieran solicitar un recurso debern esperar a qu e el semforo sea positivo, esto es: alguno de los procesos que estn usando los rec

ursos habr terminado con l e incrementar el semforo con un signal o V(s). Inicia se utiliza para inicializar el semforo antes de que se hagan peticiones s obre l, y toma por argumento a un entero. La operacin P cuando no hay un recurso d isponible, detiene la ejecucin quedando en espera activa (o durmiendo) hasta que el valor del semforo sea positivo, en cuyo caso lo reclama inmediatamente decreme ntndolo. V es la operacin inversa: hace disponible un recurso despus de que el proc eso ha terminado de usarlo. Las operaciones P y V han de ser indivisibles (o atmi cas), lo que quiere decir que cada una de las operaciones no debe ser interrumpi da en medio de su ejecucin. La operacin V es denominada a veces subir el semforo (up) y la operacin P se conoc e tambin como bajar el semforo (down), y tambin son llamadas signal y wait o soltar y tomar. Para evitar la espera activa, un semforo puede tener asociada una cola de proces os (normalmente una cola FIFO). Si un proceso efecta una operacin P en un semforo q ue tiene valor cero, el proceso es detenido y aadido a la cola del semforo. Cuando otro proceso incrementa el semforo mediante la operacin V y hay procesos en la co la asociada, se extrae uno de ellos (el primero que entr en una cola FIFO) y se r eanuda su ejecucin. Usos Los semforos se emplean para permitir el acceso a diferentes partes de programas (llamados secciones crticas) donde se manipulan variables o recursos que deben s er accedidos de forma especial. Segn el valor con que son inicializados se permit en a ms o menos procesos utilizar el recurso de forma simultnea. Un tipo simple de semforo es el binario, que puede tomar solamente los valores 0 y 1. Se inicializan en 1 y son usados cuando slo un proceso puede acceder a un r ecurso a la vez. Son esencialmente lo mismo que los mutex. Cuando el recurso est disponible, un proceso accede y decrementa el valor del semforo con la operacin P. El valor queda entonces en 0, lo que hace que si otro proceso intenta decrement arlo tenga que esperar. Cuando el proceso que decrement el semforo realiza una ope racin V, algn proceso que estaba esperando puede despertar y seguir ejecutando. Para hacer que dos procesos se ejecuten en una secuencia predeterminada puede u sarse un semforo inicializado en 0. El proceso que debe ejecutar primero en la se cuencia realiza la operacin V sobre el semforo antes del cdigo que debe ser ejecuta do despus del otro proceso. ste ejecuta la operacin P. Si el segundo proceso en la secuencia es programado para ejecutar antes que el otro, al hacer P dormir hasta que el primer proceso de la secuencia pase por su operacin V. Este modo de uso se denomina sealacin (signaling), y se usa para que un proceso o hilo de ejecucin le haga saber a otro que algo ha sucedido. Ejemplo de uso Los semforos pueden ser usados para diferentes propsitos, entre ellos: Implementar cierres de exclusin mutua o locks Barreras Permitir a un mximo de N threads acceder a un recurso, inicializando el semforo e n N Notificacin. Inicializando el semforo en 0 puede usarse para comunicacin entre thr eads sobre la disponibilidad de un recurso En el siguiente ejemplo se crean y ejecutan n procesos que intentarn entrar en s u seccin crtica cada vez que puedan, y lo lograrn siempre de a uno por vez, gracias al uso del semforo s inicializado en 1. El mismo tiene la misma funcin que un loc k. const int n /* nmero de procesos */

variable semaforo s; /* declaracin de la variable semforo de valor entero*/ Inicia (s,1) /* Inicializa un semforo con nombre s con valor 1 */ void P (int i) { while (cierto) { P(s) /* En semforos binarios, lo correcto es poner un P(s) antes de entrar en la seccin crtica, para restringir el uso de esta regin del cdigo*/ /* SECCIN CRTICA */ V(s) /* Tras la seccin crtica, volvemos a poner el semforo a 1 para que otro proceso pueda usarla */ /* RESTO DEL CDIGO */ } } void main() { Comenzar-procesos(P(1), P(2),...,P(n)); } MONITOR Los monitores son estructuras de datos utilizadas en lenguajes de programacin pa ra sincronizar dos o ms procesos o hilos de ejecucin que usan recursos compartidos . En el estudio y uso de los semforos se puede ver que las llamadas a las funcione s necesarias para utilizarlos quedan repartidas en el cdigo del programa, haciend o difcil corregir errores y asegurar el buen funcionamiento de los algoritmos. Pa ra evitar estos inconvenientes se desarrollaron los monitores. El concepto de mo nitor fue definido por primera vez por Charles Antony Richard Hoare en un artculo del ao 1974. La estructura de los monitores se ha implementado en varios lenguaj es de programacin, incluido Pascal concurrente, Modula-2, Modula-3 y Java, y como biblioteca de programas. Componentes Un monitor tiene cuatro componentes: inicializacin, datos privados, procedimiento s del monitor y cola de entrada: Inicializacin: contiene el cdigo a ser ejecutado cuando el monitor es creado Datos privados: contiene los procedimientos privados, que slo pueden ser usados desde dentro del monitor y no son visibles desde fuera Procedimientos del monitor: son los procedimientos que pueden ser llamados desd e fuera del monitor. Cola de entrada: contiene a los threads que han llamado a algn procedimiento del monitor pero no han podido adquirir permiso para ejecutarlos an. Exclusin mutua en un monitor Los monitores estn pensados para ser usados en entornos multiproceso o multihilo , y por lo tanto muchos procesos o threads pueden llamar a la vez a un procedimi ento del monitor. Los monitores garantizan que en cualquier momento, a lo sumo u n thread puede estar ejecutando dentro de un monitor. Ejecutar dentro de un moni tor significa que slo un thread estar en estado de ejecucin mientras dura la llamad a a un procedimiento del monitor. El problema de que dos threads ejecuten un mis mo procedimiento dentro del monitor es que se pueden dar condiciones de carrera,

perjudicando el resultado de los clculos. Para evitar esto y garantizar la integ ridad de los datos privados, el monitor hace cumplir la exclusin mutua implcitamen te, de modo que slo un procedimiento est siendo ejecutado a la vez. De esta forma, si un thread llama a un procedimiento mientras otro thread est dentro del monito r, se bloquear y esperar en la cola de entrada hasta que el monitor quede nuevamen te libre. Aunque se la llama cola de entrada, no debera suponerse ninguna poltica de encolado. Para que resulten tiles en un entorno de concurrencia, los monitores deben inclui r algn tipo de forma de sincronizacin. Por ejemplo, supngase un thread que est dentr o del monitor y necesita que se cumpla una condicin para poder continuar la ejecu cin. En ese caso, se debe contar con un mecanismo de bloqueo del thread, a la vez que se debe liberar el monitor para ser usado por otro hilo. Ms tarde, cuando la condicin permita al thread bloqueado continuar ejecutando, debe poder ingresar e n el monitor en el mismo lugar donde fue suspendido. Para esto los monitores pos een variables de condicin que son accesibles slo desde adentro. Existen dos funcio nes para operar con las variables de condicin: cond_wait(c): suspende la ejecucin del proceso que la llama con la condicin c. El monitor se convierte en el dueo del lock y queda disponible para que otro proces o pueda entrar Cond_signal(c): reanuda la ejecucin de algn proceso suspendido con cond_wait bajo la misma condicin. Si hay varios procesos con esas caractersticas elige uno. Si n o hay ninguno, no hace nada. Ntese que, al contrario que los semforos, la llamada a cond_signal(c) se pierde s i no hay tareas esperando en la variable de condicin c. Las variables de condicin indican eventos, y no poseen ningn valor. Si un thread tiene que esperar que ocurra un evento, se dice espera por (o en) la variable de condicin correspondiente. Si otro thread provoca un evento, simplemente utiliza la funcin cond_signal con esa condicin como parmetro. De este modo, cada variable d e condicin tiene una cola asociada para los threads que estn esperando que ocurra el evento correspondiente. Las colas se ubican en el sector de datos privados vi sto anteriormente. La poltica de insercin de procesos en las colas de las variables condicin es la FI FO, ya que asegura que ningn proceso caiga en la espera indefinida, cosa que s ocu rre con la poltica LIFO (puede que los procesos de la base de la pila nunca sean despertados) o con una poltica en la que se desbloquea a un proceso aleatorio. Tipos de monitores Antes se dijo que una llamada a la funcin cond_signal con una variable de condic in haca que un proceso que estaba esperando por esa condicin reanudara su ejecucin. Ntese que el thread que reanuda su ejecucin necesitar obtener nuevamente el lock de l monitor. Surge la siguiente pregunta: qu sucede con el thread que hizo el cond_s ignal? pierde el lock para drselo al thread que esperaba? qu thread contina con su ej ecucin? Cualquier solucin debe garantizar la exclusin mutua. Segn quin contina con la ejecucin, se diferencian dos tipos de monitores: Hoare y Mesa. Tipo Hoare En la definicin original de Hoare, el thread que ejecuta cond_signal le cede el monitor al thread que esperaba. El monitor toma entonces el lock y se lo entrega al thread durmiente, que reanuda la ejecucin. Ms tarde cuando el monitor quede li bre nuevamente el thread que cedi el lock volver a ejecutar. Ventajas: El thread que reanuda la ejecucin puede hacerlo inmediatamente sin fijarse si la condicin se cumple, porque desde que se ejecut cond_signal hasta que lleg su turno de ejecutar ningn proceso puede cambiarla. El thread despertado ya estaba esperando desde antes, por lo que podra suponerse que es ms urgente ejecutarlo a seguir con el proceso despertante.

Desventajas: Si el proceso que ejecuta cond_signal no termin con su ejecucin se necesitarn dos cambios de contexto para que vuelva a tomar el lock del monitor. Al despertar a un thread que espera en una variable de condicin, se debe asegura r que reanude su ejecucin inmediatamente. De otra forma, algn otro thread podra cam biar la condicin. Esto implica que la planificacin debe ser muy fiable, y dificult a la implementacin. Tipo Mesa Butler W. Lampson y David D. Redell en 1980 desarrollaron una definicin diferent e de monitores para el lenguaje Mesa que lidia con las desventajas de los monito res de tipo Hoare y aade algunas caractersticas. En los monitores de Lampson y Redell el thread que ejecuta cond_signal sobre un a variable de condicin contina con su ejecucin dentro del monitor. Si hay otro thre ad esperando en esa variable de condicin, se lo despierta y deja como listo. Podr intentar entrar el monitor cuando ste quede libre, aunque puede suceder que otro thread logre entrar antes. Este nuevo thread puede cambiar la condicin por la cua l el primer thread estaba durmiendo. Cuando reanude la ejecucin el durmiente, deb era verificar que la condicin efectivamente es la que necesita para seguir ejecuta ndo. En el proceso que durmi, por lo tanto, es necesario cambiar la instruccin if por while, para que al despertar compruebe nuevamente la condicin, y de no ser ci erta vuelva a llamar a cond_wait. Adems de las dos primitivas cond_wait(c) y cond_signal(c), los monitores de Lamp son y Redell poseen la funcin cond_broadcast(c), que notifica a los threads que e stn esperando en la variable de condicin c y los pone en estado listo. Al entrar a l monitor, cada thread verificar la condicin por la que estaban detenidos, al igua l que antes. Los monitores del tipo Mesa son menos propensos a errores, ya que un thread pod ra hacer una llamada incorrecta a cond_signal o a cond_broadcast sin afectar al t hread en espera, que verificar la condicin y seguir durmiendo si no fuera la espera da.