Instruccin TSL (Test and Set Lock) Detalle clave, OPERACIONES INDIVISIBLES.

Alguna Palabra de Memoria = X; Registro = Alguna Palabra de Memoria; Palabra de Memoria = Y; LeerPalabra; GuardarPalabra; Solucin: Usar una variable auxiliar llamada "lock". Misma idea del Peterson, rutinas "Entrar Regin" y "Dejar Regin". 1.- Lock tiene algn valor, tsl registres, lock copia el valor de lock en regist ro (indivisible) y asigna a lock 1 (indivisible). 2.- Revisar el registro: Posibilidades a) Si registro es 1, algn proceso haba establecido el candado, algn proceso est en l a regin crtica, se sigue revisando hasta que registro sea 0. b) Si registro es 0, ningn proceso haba establecido candado, se procede a entrar a la regin crtica. ---------------------------------------------------------------------------------Problema de Inversin de Prioridad problema del planificador. Espera activa no es buena solucin. Desperdicia CPU. --------------------------------------------------------------------------------DORMIR Y DESPERTAR Recordemos que un proceso es una actividad de algn tipo: tiene programa, entrada , salida y un estado. Por lo tanto podemos "suspender"(Dormir) un proceso y lueg o "reiniciarlo"(Despertar). Es una idea sencilla, sin embargo, la implementacin de SLEEP y WAKEUP debe ser cu idadosa y no es inmediata. A continuacin veremos un ejemplo en donde el descuido en la implementacin genera condiciones de competencia. Figura 2-11 pgina 83 . Problema Productor-Consumidor. N = 100 = nmero de ranuras en el buffer count = 0 = nmero de elementos en el buffer 1.- El 2.- El 3.- El r. 4.- El manda buffer est vaco, count = 0. Consumidor lee count y determina que vale 0. planificador decide dejar de ejecutar al Consumidor y ejecuta al Producto Producto pone un elemento en el buffer, aumenta count por 1, coount = 1 y una seal WAKEUP al Consumidor.

El consumidor todava no est dormido lgicamente, de modo que la seal de despertar se pierde.

5.- El Consumidor reanuda su ejecucin. l tiene que count es 0, lo cual es falso. y se pone a dormir. 6.- El Productor sigue llenando el buffer hasta que lo llena y se pone a dormir. $No hay candado para la variable count, el acceso no est restringido$ Segn el libro, la esencia del problema es que la seal se pierde. Una compostura rpida, agregando un bit de espera de despertar a la escena. Cuando se enva una llamada de despertar a un proceso que est despierto, se enciende este bit. Despus, cuando el proceso trata de dormirse, si el bit de espera de despert ar est encendido, se apagar, pero el proceso seguir despierto. No es buena solucin, no sirve para un nmero de procesos arbitrarios. $Es que existe un nmero mximo de procesos$ SEMFOROS Un semforo es una variable entera para guardar las seales de "despertar" junto co n dos operaciones DOWN y UP. 0 no hay sealas, valor positivo hay seales. Cabe mencionar que DOWN y UP son operaciones/acciones atmicas indivisibles. DOWN: 1.- Revisa el valor del Semforo. 2a.- Si Semforo contiene un valor positivo, decrementa ese valor por uno y termin a. 2b.- Si Semforo es 0, se duerme en espera de una seal UP al Semforo, el DOWN an no t ermina. Indivisibles. Revisar, modificar, terminar Revisar, dormir UP: 1.-Incrementa el valor del Semforo. 2.-Si hay uno o ms procesos esperando por una seal de ese Semforo, el Sistema escog e uno de esos procesos, y permite que termine/complete el DOWN que lo durmi. Indivisibles. Incrementar Incrementar y despertar. $No es claro que la clave son las operaciones indivisibles$ Resolucin de Productor-Consumidor usando semforos.

Se utilizan tres semforos. Competencia Mutex = 1 (Maneja la entrada y salida de la regin crtica) Sincronizacin Empty = N (Nmero de ranuras vacas) Full = 0 (Nmero de ranuras llenas) ------------Espero poder explicar los detalles -------------La implementacin de semforos debe ser cuidados, por poner un ejemplo, invirtiendo los down, los procesos se pueden bloquear. los dos DOWN del cdigo del productor se invirtiera, de modo que mutex se incrementara antes que empty en lugar de despus de l. Si el buffer estuviera compl etamente lleno, el productor se bloqueara, con mutex puesto en O. En consecuencia, la prxima vez que el consumidor tratara de acceder al buffer ejecutara DOWN con mutex, que ahora es O, y tambin se bloqueara. Ambos procesos permaneceran bloqueados indefinidamente y ya no se efectuara ms trabajo. -----------------------------------------------------------MONITORES Es una primitiva de alto nivel, comparada con la de bajo nivel en los semforos. E n los semforos, errores sutiles cuestan caro, sera deseable ofrecer una forma fcil de lograr exclusin mutua. Un monitor es una coleccin de procedimientos, variables y estructuras de datos qu e se agrupan en un tipo especial de mdulo o paquete. En un monitor slo puede esta activo, a lo ms, un proceso en un momento dado. Los procesos pueden invocar los procedimientos de un monitor en el momento en qu e deseen, pero no pueden acceder directamente a las estructuras de datos interna s del monitor desde procedimientos declarados afuera del monitor. Los monitores son una construccin den lenguaje de programacin, el compilador debe saber que son especiales y manejar las llamadas a procedimientos de manera espec ial . Es responsabilidad del compilador implementar la exclusin mutua en las entr adas a monitores, pero una forma comn es usar un semforo binario. La sincronizacin se logra con WAIT y SIGNAL. A fin de evitar la presencia de dos procesos activos en el monitor al mismo tiem po, necesitamos una regla que nos diga qu sucede despus de ejecutarse SIGNAL. Hoar e propuso dejar que el proceso recin despertado se ejecute, suspendiendo el otro. Brinch Hansen propuso sortear el problema exigiendo al proceso que ejecut SIGNAL salir inmediatamente del monitor. Dicho de otro modo, una instruccin SIGNAL slo p uede aparecer como ltima instruccin de un procedimiento de monitor. Se usar la segunda. Es ms sencilla. Fcil de implementar. La conclusin es que los semforos son de nivel demasiado bajo y que los monitores sl

o pueden usarse con unos cuantos lenguajes de programacin. Adems, ninguna de las p rimitivas contempla el intercambio de informacin entre mquinas. Se necesita otra c osa. Hasta ahora las soluciones usan una construccin del lenguaje, que, puede o no exi stir. TRANSFERENCIA DE MENSAJES Mtodo de comunicacin que utiliza dos operaciones/acciones/llamadas SEND y RECEIVE Leer la expo de Alonso. Nada ms. Suponemos que todos los mensajes tienen el mismo tamao y que el sistema operativo coloca automticamente en buffers los mensajes enviados pero an no recibidos. En esta solucin se usa un total de N mensa jes, anlogos a las N ranuras de un buffer en memoria compartida. El consumidor inicia enviando N mens ajes vacos al productor. Cada vez que el productor tiene un elemento que entregar al consumido r, toma un mensaje vaco y devuelve uno lleno. De este modo, el nmero total de mensajes en el sistema permanece constante y pueden almacenarse en una cantidad de memoria que se conoce con antelacin. -------------------------------------------