Principios generales de concurrencia

En un sistema multiprogramado con un nico procesador, los procesos se intercalan en el tiempo para dar la apariencia de ejecucin simultnea (figura a). Aunque no se consigue un proceso paralelo real y aunque se produce una cierta sobrecarga en los intercambios de procesos de un sitio a otro, la ejecucin intercalada produce beneficios en la eficiencia del procesamiento y en la estructura de los programas. Tiempo P1 P2 P3 a) Intercalacin

P1 P2 P3 b) Intercalacin y superposicin

En un sistema con varios procesadores, no solo es posible intercalar los procesos, sino tambin superponerlos (figura b). Ambas tcnicas pueden contemplarse como ejemplo de proceso concurrente y ambas plantean los mismos problemas. En el caso de un sistema monoprocesador, los problemas creados por la multiprogramacin parten del hecho de que la velocidad relativa de ejecucin de los procesos no pueden predecirse. As surgen las siguientes dificultades:

La comparticin de recursos globales esta llena de riesgos: Si dos procesadores hacen uso al mismo tiempo de la misma variable globaly ambos llevan a cabo tanto lecturas como escrituras sobre la variable, el orden sobre el que se ejecuten las lecturas y escrituras es crtico. Para el sistema operativo resulta difcil asignar los recursos de forma optima: el procesador A puede solicitar el uso de un canal de E/S en particular y suspenderse antes de hacer uso del canal. Si el SO bloquea el canal e impide su uso por parte de otros procesos, se tiene una cierta ineficiencia. Resulta difcil localizar un error de programacin porque los resultados no son normalmente reproducibles. Todas las dificultades anteriores se presentan tambin en los sistemas multiprocesador ya que tambin en ellos es impredecible la velocidad relativa de ejecucin de los procesos.

Un ejemplo sencillo. procedure echo; var sal, ent : carcter; begin entrada(ent, teclado); sal:= ent; salida(sal, terminal); end. Este procedimiento muestra la funcion de eco(echo) de un carcter en el terminal; la entrada se obtiene del teclado con una pulsacion cada vez, cada carcter de entrada se almacena en la variable ent, se transfiere a la variable sal y se muestra en la pantalla. Considerese un sistema con un unico procesador que da soporte a un usuario el cual puede pasar de una aplicacin a otra y todas las aplicacines usan el mismo teclado para la entrada y la misma pantalla para la salida. Este es un procedimiento compartido que se carga en una parte de memoria global, esta comparticion puede dar lugar a problemas. Considerese la siguiente secuencia. 1.- El proceso P1 llama al procedimiento echo y es interrumpido inmediatamente despues de terminar la funcion de entrada. El ultimo carcter leido x estara almacenada en la variable ent. 2.- Se activa el proceso P2 y llama al procedimiento echo, que ejecuta hasta el final y muestra un carcter y en la pantalla. 3.- Se reanuda el proceso P1 y el valor de x ha sido sobreescrito en la variable ent y por tanto se ha perdido. Ahora ent contiene el valor y, que se transfiere a la variable sal y se visualiza. Hay que tener en cuenta que es necesario aprender a proteger las variables globales compartidas y que la unica forma de hacerlo es controlar el codigo que accede a la variable.En un sistema multiprocesador surge el mismo problema de proteccion de los recursos compartidos y es valida la misma solucion: Supongase que no hay un mecanismo para controlar el acceso a la variable local compartida: 1.- LOS procesos P1 y P2 estan ejecutando, cada uno en un procesador diferente. Ambos invocan al procedimiento echo. 2.- Se producen los siguientes sucesos; los sucesos de la misma linea tienen lugar en paralelo.

PROCESO P1 . Entrada(ent, teclado) Sal:= ent Salida(sal, terminal) .

PROCESO P2 . . Entrada(ent, teclado) Sal:= ent Salida(sal, terminal) .

El resultado es que el carcter de entrada se pierde antes de visualizarse y el carcter de entrada de P2 se visualiza tanto por P1 como P2 entonces se aplica la norma de que solo un proceso puede estar en echo en cada instante. LABORES DEL SISTEMA OPERATIVO

El sistema operativo sigue procesos activos por medio de bloques de control de procesos, debe asignar y quitar recursos a cada proceso activo. Entre estos recursos se encuentran tipo de procesador, memoria, archivos, dispositivos de E/S. El S.O debe proteger los datos y los recursos fsicos de cada proceso contra ingerencias no intencionadas de otros procesos. Los resultados de un proceso deben ser independientes de la velocidad a la que se realiza la ejecucin con respecto a otros procesos concurrentes. Interaccin entre procesos La concurrencia de los posesos puede ser resultado de la multiprogramacin de aplicaciones independientes con varios procesos y del uso de la estructura de procesos en el S.O. Los procesos no tienen conocimiento de los dems.= son independientes no estn pensados para operar juntos Los procesos tienen un conocimiento indirecto de los otros= no conocen necesariamente a los otros por su nombre, pero comparten acceso con algunos objetos como el Buffer E/S. Los procesos tienen un conocimiento directo de los otros=comunicarse por el nombre y trabajan conjuntamente en alguna actividad Competencia entre procesos por los recursos Si dos procesos desean acceder a un nico recuso el S.O. le asignara el recurso a uno de ellos y el otro tendra que esperar, en algunos casos se retrasara o hasta se bloqueara. Cuando hay procesos en competencia hay que solucionar tres problemas de control. La necesidad de exclusin mutua solo un programa puede acceder a su seccin critica en un momento dado este crea dos problemas de control uno de interbloqueo cuando se esperan recursos y no llegan por que estn siendo ocupados por otro y el de inanicin que es cuando un proceso manda una peticin a un recurso y esta no se lo otorga por que esta siendo repartido a los dems procesos y puede quedar negado indefinidamente.

COOPERACION ENTRE PROCESOS POR COMPARTICION Comprende los procesos que interactuan con otros sin tener conocimiento explicito de ellos por ejemplo varios procesos pueden tener acceso a variables compartidas, archivos y bases de datos compartidas. Pueden emplear y actualizar los datos compartidos sin hacer referencia a los otros procesos, pero son coscientes de que estos otros pueden tener acceso a los mismos datos. Puesto que los datos se guardan en recursos (dispositivos, memoria), tambien se presentan los problemas de exclusion mutua, interbloqueo e inanicion. Sin embargo, ante estos problemas, se debe introducir un nuevo requisito: la coherencia de los datos. Supngase que dos datos a y b, deben cumplir la relacin a = b. es decir, cualquier programa que actualice un valor debe tambin actualizar el otro para que se siga cumpliendo la relacin. P1: a := a+1; b:= b+1;

P2: b:= 2*b; a:= 2*a; Considrese ahora la siguiente ejecucin: a:= a+1 b:= 2*b b:= b+1 a:= 2*a Al final no se mantiene la condicin a = b. esto puede evitarse declarando la secuencia completa de cada proceso como seccin critica, se ve que el concepto de seccin critica es importante en el caso de cooperacin por comparticin adems si se usan secciones criticas para garantizar la integridad de los datos puede no haber ningn recurso o variable que puede identificar como argumento (se considera al argumento como un identificador compartido entre procesos). COOPERACION ENTRE PROCESOS POR COMUNICACIN En los dos primeros casos expuestos, cada proceso posee su propio entorno aislado, que no incluye a los otros procesos. Las interacciones entre los procesos son indirectas. En ambos casos existe comparticin. Cuando los procesos cooperan por comunicacin, en cambio, los distintos procesos participan en una labor comn que une a todos los procesos. La comunicacin es una manera de sincronizar o coordinar las distintas actividades. Puesto que en los mensajes no se comparte nada entre los procesos, no es necesario el control de la exclusin mutua para este tipo de cooperacin. Sin embargo, los problemas de interbloqueo e inanicin siguen presentes. Como ejemplo de inanicin, considere tres procesos, P1,P2 y P3, que muestran el comportamiento siguiente: P1 intenta comunicar repetidas veces bien con P2 o con P3 y tanto P2 como P3 intentar comunicar con P1. Puede surgir una secuencia en la que P1 y P2 intercambien informacin repetidamente, mientras P3 est bloqueado esperando una comunicacin desde P1. No hay interbloqueo porque P1 permanece activo, pero P3 sufre inanicin. Requisitos para la exclusin mutua El uso adecuado de la concurrencia entre procesos exige la capacidad de definir secciones crticas y hacer cumplir la exclusin mutua. Esto es fundamental para cualquier esquema de proceso concurrente. Cualquier servicio o capacidad que d soporte para la exclusin mutua debe cumplir los requisitos siguientes: 1. Debe cumplirse la exclusin mutua: Slo un proceso, de entre todos los que poseen secciones crticas por el mismo recurso u objeto compartido, debe tener permiso para entrar en ella en un instante dado. 2. Un proceso que se interrumpe en una seccin no crtica debe hacerlo sin estorbar a los otros procesos. 3. Un proceso no debe poder solicitar acceso a una seccin crtica para despus ser demorado indefinidamente; no puede permitirse el interbloqueo o la inanicin. 4. Cuando ningn proceso est en su seccin crtica, cualquier proceso que solicite entrar en la suya debe poder hacerlo sin dilacin. 5. No se pueden hacer suposiciones sobre la velocidad relativa de los procesos o su numer. 6. Un proceso permanece en su seccin crtica slo por un tiempo finito.

Hay varias formas de satisfacer los requisitos de exclusin mutua. Una manera es dejar la responsabilidad a los procesos que deseen ejecutar concurrentemente. As pues, tanto si son programas del sistema como de aplicacin, los procesos deben coordinarse unos con otros para cumplir la exclusin mutua, sin ayuda por parte del lenguaje de programacin o del sistema operativo. Estos mtodos se conocen como soluciones por software. Un segundo mtodo propone el uso de instrucciones de la mquina a tal efecto. Estas tienen la ventaja de reducir la sobrecarga pero. El tercer mtodo consiste en dar algn tipo de soporte en el sistema operativo.

PRIMER INTENTO Como ya sabemos, cualquier intento de exclusin mutua depende de algunos mecanismos bsicos de exclusin en el hardware. Como la restriccin de que solo se puede permitir un acceso a una posicin de memoria en cada instante. Como metfora de esto tenemos el protocolo del igl. Tanto en la entrada como en el mismo igl solo cabe una persona a la vez. Dentro, hay una pizarra donde se puede escribir solo un valor. El protocolo es este. Un proceso ya sea P1 o P0 entra al igl, si su numero esta escrito en la pizarra el proceso puede abandonar el igl y continuar con su seccin critica. En caso contrario abandona el igl y solo espera y de ves en cuando entra al igl para mirar la pizarra las veces que sean necesarias hasta que se le permita entrar a su seccin critica. Este proceso se denomina espera activa por que un proceso no puede hacer nada hasta que se le permite entrar en su seccin critica. Al esperar debe comprobar peridicamente el igl as consume tiempo del procesador; es decir, esta activo mientras espera. Una vez que un proceso termina con su seccin critica debe volver a el igl y escribir el numero del otro proceso en la pizarra. En trminos de programacin, hay una variable global compartida: var truno=0 .. 1;

P0 . . While turno = 0 do {nada}; <seccin critica> turno=1; .

P1 . . While turno = 1 do {nada}; <seccin critica> turno=0; .

Esta solucin cumple con la exclusin mutua. Pero tiene 2 inconvenientes:

Los procesos deben alternarse estrictamente el uso de su seccin critica, el ritmo de ejecucin viene dictado por el mas lento, si P0 usa su seccin critica a un ritmo mucho menor que P1 esto implica que P1 esta obligado a adoptar el ritmo de P0. Si un proceso falla en su seccin crtica o fuera de ella, el otro proceso se bloquea permanentemente.

La estructura anterior fue diseada para pasar el control de un proceso a otro, dicha estructura se llama corrutina. SEGUNDO INTENTO El problema con el primer intento es que almacena el nombre del proceso que puede entrar en su seccin critica cuando, lo que se requiere es informacin del estado de cada proceso. Cada proceso debe de tener su propio igl con su propia pizarra para poder manifestar el estado en el que se encuentra y en caso de que uno sea comido por un oso polar, cada proceso puede ver el estado del otro, pero no modificarlo. Ahora cuando un proceso desea entrar en su seccin crtica, comprueba peridicamente la pizarra del otro hasta que diga falso, esto nos dice que el otro proceso no est en su seccin crtica. Entonces entra a su propio igl y escribe en su pizarra cierto. El proceso puede continuar con su seccin crtica. Cuando deja su seccin critica, cambia su pizarra para que ponga falso. La global compartida ahora es: var seal: array [01] of booleano;

C0

Cierto
Que esta inicializada con falso. El programa para los dos procesos es: PROCESO 0 * * while seal [1] do {nada}; seal [0]:=cierto; <seccin critica> seal [0]:=falso; * * while seal [0] do {nada}; seal [1]:=cierto; <seccin critica> seal [1]:=falso; PROCESO 1

C1 Falso

Por lo tanto si el otro proceso falla, el otro proceso no se queda bloqueado. De hecho, el otro proceso puede entrar en tantas veces quiera a su seccin critica, porque la seal en el otro proceso siempre est en falso. Pero, si un proceso falla en su seccin critica, el otro proceso est bloqueado permanentemente. En realidad, esta solucin es peor que la primera, pues no siempre se garantiza la exclusin mutua. Consideremos la siguiente secuencia: P0 ejecuta la sentencia while y encuentra seal [1] a falso. P1 ejecuta la sentencia while y encuentra seal [0] a falso. P0 pone seal [0] a cierto y entra en su seccin critica. P1 pone seal [1] a cierto y entra en su seccin critica.

Puesto que ambos procesos estn en sus secciones criticas, el programa es incorrecto. El problema est en la solucin propuesta no es independiente de la velocidad de ejecucin relativa de los procesos. 3er intento Segundo intento falla porque un proceso puede cambiar su estado despus de que el otro proceso lo ha comprobado, pero antes de que pueda entrar en su sesin critica.

Quiz este problema se pueda solucionar con un simple intercambio de 2 lneas.

Proceso 0 Seal [0]:= cierto; While seal [1] do {nada}; <Seccin critica> Seal [0]:=falso;

Proceso 1 seal [1]:=cierto While seal [0] do {nada}; <seccin critica> seal [1]:=falso;

Si falla un proceso dentro de la seccin critica, incluyendo el cdigo para dar valor a las seales que controla el acceso, el otro proceso se bloquea. Si un proceso falla fuera de la seccin crtica el otro proceso no se bloqueara. CUARTO INTENTO En el tercer intento, un proceso fijaba su estado sin conocer el estado de otro. El interbloqueo se produce porque cada proceso puede insistir en su derecho para entrar en su seccin critica; no hay opcin para volver atrs desde esta situacin. Se puede arreglar esto haciendo que los procesos sean ms educados: Deben activar su seal para indicar que desean entrar en la seccin crtica, pero deben estar listos para desactivar la seal y ceder la preferencia al otro proceso:

Esta solucin se aproxima a la correcta pero todava es defectuosa. Considresela siguiente secuencia de sucesos: P0 pone seal [0] a cierto P1 pone seal[1] a cierto P0 comprueba seal [1] P1 comprueba seal [0] P0 pone seal [0] a falso P1 pone seal [1] a falso P0 pone seal [0] a cierto P1 pone seal [1] a cierto

PROCESO 0 . . Seal[0]:=cierto; While seal[1] do Begin Seal[0]:=falso; <espera cierto tiempo> Seal[0]:=cierto; End; <Seccin critica> Seal [0]:=falso; .

PROCESO 1 . . Seal[1]:=cierto; While seal[0] do Begin Seal[1]:=falso; <Espera cierto tiempo> Seal[1]:=cierto; End; <Seccin critica> Seal [1]:=falso; .

Esta secuencia podra prolongarse indefinidamente y ningn proceso podra entrar en su seccin critica. Cualquier cambio en la velocidad relativa de los dos procesos rompera este ciclo y permitira a uno entrar en la seccin crtica. Aunque no es probable que esta secuencia se mantenga por mucho tiempo, es una situacin posible. As pues, se rechaza el cuarto intento. UNA SOLUCIN CORRECTA Se observa el estado de ambos procesos q vienen dados por la variable seal, pero el cuarto intento demuestra que no es suficiente. Entonces se hace necesario imponer algn orden en la actividad de los dos procesos para evitar el problema de cortesa mutua. La variable turno indica en este caso que proceso tiene prioridad para exigir la entrada a la seccin critica. Para darle una solucin a este problema se puede ejemplificar mediante trminos de igles. Donde hay un igl rbitro con una pizarra llamada turno. Cuando P0 quiere entrar en su seccin critica, pone su seal a cierto y despus va y mira la seal de P1 si esta en falso P0 puede entrar en su seccin critica. Y en otro caso P0 va a consultar al rbitro. Si encuentra el turno=0, es momento de insistir y comprueba peridicamente el igl de P1. Este se percatara de que es momento de ceder y escribir falso en su pizarra, permitiendo continuar a P0. Despus de que P0 ha ejecutado su seccin crtica pone su seal a falso para liberar la seccin crtica y pone turno en 1 para traspasar el derecho de insistir a P1. ALGORITMO DE PETERSON Peterson desarrolla una solucin simple y elegante. Como antes la variable global seal indica la posicin de cada proceso con respecto a la exclusin mutua y la variable global turno resuelve los conflictos de simultaneidad. Se tiene que se puede demostrar que se cumple la exclusin mutua. Ejemplo: Considrese el proceso P0. Una vez que ha puesto seal 0 a cierto, P1 no puede entrar en su seccin critica. Si P1 esta aun en su seccin critica, seal [1]=cierto y P0 est bloqueado para entrar en su seccin critica. Por otro lado se impide el bloqueo mutuo. Supongamos que P0 est bloqueado en su bucle while. Esto quiere decir que seal [1] es cierto y turno=1. P0 puede entrar en su seccin crtica cuando seal [1] se ponga falso y turno en 0. Entonces considrese los siguientes casos: 1.- P1 no desea entrar en su seccin crtica. Esto es imposible porque se dice que seal [1]= falso. 2.- P1 est esperando entrar en su seccin crtica. Es imposible tambin porque si turno=1, P1 podr entrar en su seccin critica. 3.- P1 entra en su seccin crtica varias veces y monopoliza su acceso. Esto no puedo pasar porque P1 est obligado a dar a P0 una oportunidad poniendo a turno en 0 antes de cada intento de entrar en su seccin crtica.

EXCLUSION MUTUA: SOLUCIONES POR HARDWARE

Inhabilitacin de interrupciones. En una maquina monoprocesador los procesos solo pueden intercalarse, y no ejecutarse todos a la vez. Un proceso se seguir ejecutando hasta que solicite un servicio del sistema operativo o hasta que sea interrumpido. Para garantizar la exclusin mutua, es suficiente con impedir que un proceso sea interrumpido, esta capacidad puede ofrecerse en forma de instrucciones primitivas definidas por el ncleo del sistema para habilitar o inhabilitar interrupciones.

Esta solucin no sera eficaz en los sistemas multiprocesador, cuando el sistema tenga ms de un procesador, es posible que haya ms de un proceso en ejecucin al mismo tiempo. En este caso, inhabilitar las interrupciones no garantizara la exclusin mutua. Puesto que la seccin crtica no puede ser interrumpida, la exclusin mutua est garantizada. Sin embargo, el precio de esta solucin es alto. La eficiencia de la ejecucin puede verse notablemente degradada debido a que se limita la capacidad del procesador para intercalar programas. Un segundo problema es que est tcnica no funciona en arquitecturas de multiprocesador. Cuando el sistema tenga ms de un procesador, es posible (y habitual) que haya ms de un proceso ejecutndose al mismo tiempo. En este caso, inhabilitar las interrupciones no garantiza la exclusin mutua.

SEMFOROS

Se vuelven a considerar ahora los mecanismos que se usan en el sistema operativo y en los lenguajes de programacin para dar soporte a la concurrencia.

El primer gran avance en la resolucin de los problemas de procesos concurrentes lleg en 1965, con el tratado de Dijkstra sobre la cooperacin entre procesos secuenciales.

El principio fundamental es el siguiente: Dos o ms procesos pueden cooperar por medio de simples seales, de forma que se pueda obligar a detenerse a un proceso en una posicin determinada hasta que reciba una seal especfica. Para la sealizacin, se usan variables especiales llamados semforos.

Para transmitir una seal por el semforo s, los procesos ejecutan la primitiva signal(s).

Para recibir una seal del semforo s, los procesos ejecutan la primitiva wait(s); si la seal correspondiente an no se ha transmitido, el proceso es suspendido hasta que tenga lugar la transmisin".

Para lograr el efecto deseado, se pueden contemplar los semforos como variables que tienen un valor entero sobre el que se definen las tres operaciones siguientes:

1. 2. 3.

Un semforo puede inicializarse con un valor positivo. La operacin waitdecrementa el valor del semforo. Si el valor se hace negativo, el proceso que ejecuta el waitse bloquea. La operacin signa!incrementa el valor del semforo. Si el valor es negativo, se desbloquea a un proceso bloqueado por una operacin wait.

Aparte de estas tres operaciones, no hay forma de examinar o manipular los semforos.

Las primitivas waity signalse suponen atmicas, es decir, no pueden ser interrumpidas y cada rutina puede considerarse como un paso indivisible.

Un semforo binario slo puede tomar los valores 0 y 1. En principio, los semforos binarios son ms sencillos de implementar.

Tanto en los semforos como en los semforos binarios se emplea una cola para mantener los procesos esperando en el semforo. La definicin no dicta el orden en el que se quitan los procesos de dicha cola. La poltica ms equitativa es la FFO: el proceso que ha estado bloqueado durante ms tiempo se libera de la cola. La nica exigencia estricta es que un proceso no debe quedar retenido en la cola de un semforo indefinidamente porque otros procesos tengan preferencia.

Problema de la Barbera La barbera tiene 3 sillas, 3 barberos, 1 zona de espera en la que se pueden acomodar 4 clientes en un sof y 1 sala de espera en la que pueden esperar el resto de los clientes de pie. Las medidas contra incendios limitan el nmero total de clientes a 20. En este ejemplo se procesarn 50 clientes. Un cliente no entrara en la tienda si su capacidad esta al completo. Cuando un barbero esta libre, se atiende al cliente que ha pasado ms tiempo en el sof, y de la sala de espera el que ha estado ms tiempo de pie es el que pasa al sof. Cuando un barbero finaliza el corte de pelo de un cliente, cualquier barbero puede aceptar el pago, pero, debido a que solo hay una caja registradora, slo se acepta el pago de un cliente cada vez. Los barberos dividen su tiempo entre corte de pelo, pagos y dormir. Una barbera no equitativa Se activan 50 clientes, 3 barberos, y el proceso cajero. Consideremos el propsito y la posicin de los operadores de sincronizacin. *Capacidad de tienda y sof: max_capacidad =capacidad de la tienda.------se decrementa en uno cada que un cliente intenta entrar. Incremente cada vez que un cliente sale. Si est llena la tienda el proceso de este cliente se detiene con la funcin wait. Wait y signal se encargan de las acciones sentarse y levantarse. sof= capacidad del sof. *Capacidad de sillas de barbero: silla_barbero= se asegura de que ms de tres clientes no estn sentados en la misma silla. Un cliente no se levantara del sof hasta que est libre al menos una silla y cada barbero indicar cuando un cliente deja una silla. As se garantiza un acceso equitativo a las sillas por la organizacin de las colas de semforos. Cliente_listo= indica a un barbero que estuviera dormido que un cliente acaba de sentarse en una silla.

Barbera Caja Silla s

sof

Terminado= para indicar que un corte de pelo a finalizado Dejar_silla_barbero=para no invitar a un nuevo cliente hasta que el cliente que esta haya anunciado su salida.

Problema Del Productor/Consumidor El planteamiento general es el siguiente: uno o mas productores generan cierto tipos de datos (registros, caracteres) y los situan en un buffer. Un nico consumidor saca elementos del buffer de uno en uno. Se consideraran varias soluciones a este problema Supnganse que el buffer es ilimitado y que consiste en un vector lineal de elementos. Repeat Producir elemento v; b[ent]:= v; ent:=ent+1 forever; /*****Funcion del consumidor******/ Repeat While ent <= sal do {nada}; w:=b[sal] sal:=sal+1 consumir element w

forever; b[1] b[2] b[3] b[4] b[5] .

sal

ent

El productor puede generar elementos y almacenarlos en el buffer a su propio ritmo e incrementa un ndice (ent). El consumidor procede de forma similar, pero debe de asegurar de que no esta tratando de leer de un buffer vacio por lo cual debe asegurarse de que el productor ya ha procesado (ent > sal). Se implementara semforos binarios en lugar de solucionarlo con ndices ent y sal, guardando la cuenta de elementos del buffer (n = ent - sal). Usando semforo s para cumplir la exclusin mutua y el semforo retraso para obligar al consumidor a esperar si el buffer esta vacio program productor_consumidor; var n: entero; s: semforo(*binario*)(:=1); retraso: semforo(*binario*)(:=0) procedure productor; begin repeat producir; wait B(s); aadir; n:=n+1; if n=1 then signalB(retraso); signal(s) forever end; procedure consumidor; begin repeat waitB(s); tomar;

n:=n-1; signalB(s); consumir; if n=0 then waitB(retraso) forever end; begin (*programa_principal*) n:=0; parbegin productor;consumidor parend end

4.5 Monitores.

Los monitores son estructuras de un lenguaje de programacin que ofrecen una funcionalidad equivalente a la de los semforos y que son ms fciles de controlar. Comenzaremos viendo la versin de hoare[HOAR74]: Monitores con seales. Un monitor es un modulo de software que consta de uno o mas procedimientos, una secuencia de inicializacin y unos datos locales. Caractersticas: 1. 2. 3. Las variables de datos locales son solo accesibles para procedimientos del monitor y no para procedimientos externos. Un proceso entra en el monitor invocando a uno de sus procedimientos. Solo un proceso puede estar ejecutndose en el monitor en un momento dado; cualquier otro proceso que quiera entrar al monitor quedara suspendido mientras espera a que el monitor de libere.

Si se cumple la norma de un proceso a la vez, el monitor puede ofrecer servicio de exclusin mutua. Las variables de datos del monitor pueden ser accedidas solo por un proceso a la vez. D e esta manera una estructura de datos compartida puede protegerse dentro del monitor.

Un monitor proporciona sincronizacinpor medio de las variables de condicin que son solo accesibles desde dentro del monitor. Hay 2 funciones para manejar las variables de condicin:

cwait(c): suspende la ejecucin del proceso llamado bajo la condicin c. El monitor esta ahora disponible para ser usado por otro proceso csignal(c):Reanuda la ejecucin de algn proceso suspendido despus de uncwait(c)bajo la misma condicin. Si hay varios procesos, elige uno de ellos; sino hay no hace nada.

Figura que muestra la estructura de un monitor

Puede considerarse que el monitor tiene un nico puerto de entrada que esta custodiado para que solamente un proceso pueda estar en el monitor a la vez. Otros procesos que intenten entrar al monitor se aadirn a una cola de procesos supendidos mientras que esperan a que el monitor este disponible. Una vez que un

proceso este dentro puede suspenderse a si mismo temporalmente bajo la condicin x ejecutando cwait(x); Entonces se situa en una cola de procesos que esperan volver a entrar cuanco la condicin cambie. Si un proceso que esta ejecutando en el monitor detecta un cambio en una variable de condicin x, se ejecuta csignal(x), lo que avisa a la cola de condicin correspondiente de que la condicin ha cambiado.

Una de las principales ventajas que tienen los monitores sobre los semforos es que todas las funciones de sincronizacin estn confinadas dentro del monitor, de esta manera es mas fcil ver que la sincronizacin se llevo acabo correctamente y detectar fallos. Monitores con notificacin y difusin. La definicin que hace hoare de los monitores [HOAR74]exige que, si hay al menos un proceso en una cola de condicin, un proceso de la misma cola deber ejecutar en cuanto otro proceso ejecute csignalpara la condicin. As pues, el proceso que ejecuta el csignaldebe salir inmediatamente del monitor o suspenderse en el monitor. Hay 2 grandes inconvenientes en esta solucin: Si el proceso que ejecuta elcsignal no abandona el monitor, hacen 2 cambios de contexto adicionales: 1.- para suspender el proceso. 2.- para reanudarlo cuando el monitor este listo.

Cuando se ejecuta en csignal debe activarse inmediatamente un proceso de la cola de la condicin correspondiente y el planificador debe asegurarse de que ningn otro proceso entre al monito antes dela activacin. Si no es as la condicin bajo la que se a activado el proceso podra cambiar. Lampson y Redelldesarrollaron una definicin diferente [LAMP80] dando solucin a los problemas anteriores; la estructura de monitores de Mesa. En mesa, la primitiva csignalse sustituye por cnotify, de esta manera cuando un proceso dentro del monitor ejecuta cnotify(x), origina una notificacin hacia la cola de condicin x, pero el proceso que da la seal puede continuar ejecutando. El resultado de la notificacin hace que el proceso de la cabeza de la cola de condicin ser reanudado en el futuro cercano, cuando el monitor este libre. Con la norma de notificar a los proceso en vez de activarlos a la fuerza es posible aadir una primitiva de difusin cbroadcast. Esta difusin provoca que todos los procesos que estn esperando por una condicin se siten en el estado de listo. Esto es conveniente en las situaciones donde un proceso no sabe cuando reactivarse. Una ventaja de los monitores Lampsoon/Redellsobre los Hoare es que el mtodo [LAMP80] es menos propenso a errores. Otra ventaja es que presentan un mtodo msa modular de construccin de programas Problemas de los Lectores/Escritores El problema de los lectores/escritores se define de la siguiente manera: Existe un rea de datos compartida entre serie de procesos. El rea de datos puede ser un archivo, un bloque de memoria principal e incluso un banco de registros de procesador. Hay algunos procesos que solo leen los datos (lectores) y otros solo escriben datos (escritores).

Se deben de satisfacer las siguientes condiciones: Cualquier nmero de lectores puede leer el archivo simultneamente. Solo puede escribir en el archivo un escritor en cada instante. Si un escritor esta accediendo al archivo, ningn lector puede leerlo.

En el problema de lectores/escritores, ni los lectores escriben en el rea ni los escritores leen. Prioridad a los lectores Es una solucin que tiene semforos mostrando un caso de un lector y otro de un escritor, la solucin no cambia para varios lectores y escritores. El proceso escritor es sencillo. El semforo esem se usa para respetar la exclusin mutua. Mientras que un escritor esta accediendo a los datos compartidos, ningn escritor ni ningn lector podr acceder. El proceso lector tambin usa el semforo esem para respetar la exclusin mutua. Sin embargo para que se permita varios lectores, hace falta que, cuando no haya ninguno, el primer lector que lo intente tenga que esperar en esem. Cuando ya hay almenos un lector, los lectores posteriores no necesitan espera antes de entrar. Prioridad a los escritores Una vez que un lector a comenzado a acceder a los datos, es posible que los lectores mantengan el control de rea de datos mientras que haiga al menos uno leyendo. Por tanto, los escritores estn sujetos a iniciacin. Para los escritores, se aaden los siguientes semforos y variables al ya definido: Un semforo isem que inhibe todas las lecturas mientras haya al menos un escritor que desee acceder a los datos. Una variable contese que controla la activacin de Isem. Un semforo y que controla la actualizacin de contese.

No debe permitirse que se construya una cola grande sobre Isem, pues los escritores no serian capaces de saltarla. Por lo tanto solo se permite a un lector ponerse en cola en Isem y todos los dems lectores deben de ponerse en cola en un semforo z inmediatamente antes de esperar en Isem. La siguiente tabla resume las posibilidades:

Estado de las colas del proceso anterior: Solo lectores en el sistema

Activar esem Sin colas Activar esem e Isem Los escritores se encolan en esem Esem activado por un lector Isem activado por un escritor Todos los escritores se ponen en cola en esem Un lector se pone en cola en Isem Los otros lectores se ponen en cola en z. Los escritores activan esem Los lectores activan Isem Todos los escritores se ponen en cola en esem Un lector se pone en cola en Isem

Solo escritores en el sistema

Lectores y escritores con un lector primero

Lectores y escritores con un escritor primero

Los otros lectores se ponen en cola en z

Definicin de interbloqueo Un conjunto de procesos que compiten por los recursos del sistema o bien se comunican unos a otros Se cuenta con recursos reutilizables y consumibles, como ejemplo de reutilizables estn la memoria y el procesador y consumibles las interrupciones y seales

Condiciones de interbloqueo Deben darse 3 condiciones para que pueda producirse un interbloqueo: 1.- exclusin mutua: solo un proceso puede usar un nico recurso simultaneamente 2.- retencin y esperar: un proceso puede retener unos recursos mientras espera que otros le sean asignados. 3.- no apropiacin: ningn proceso puede ser forzado a abandonar un recurso que tenga 4.-es una condicin extra; que se llama crculo vicioso de espera: existe una cadena cerrada de espera en el cual cada proceso retiene por lo menos a un solo recurso que necesita el sig. Proceso y as sucesivamente

Recurso A Solicitud Retenido por Solicitud Retenido por Recurso B

Las 3 primeras condiciones son necesarias pero no suficientes para que exista un interbloqueo y la cuarta es una consecuencia potencial de la primera y as se da un crculo de espera irresoluble que es la definicin de interbloqueo. En si esta ultima de da como consecuencia de las otras tres. PREVENCIN DEL INTERBLOQUEO La estrategia consiste en disear un sistema de manera que este excluida la posibilidad de interbloqueo. Existen dos tipos de interbloqueo: Mtodo directo: evita la aparicin del circulo vicioso de espera. Mtodo indirecto: consiste en impedir la aparicin de alguna de las tres condiciones necesarias(exclusin mutua, retencin y esperar, no apropiacin)

EXCLUSIN MUTUA:

No puede anularse. Si un recurso necesita exclusin mutua, el sistema operativo debe soportarla. Algunos recursos pueden permitir varios accesos a la lectura, pero solo procesos exclusivos para la escritura. En este caso se puede producir interbloqueo si ms de un proceso necesita permiso de escritura. RETENCIN Y ESPERA Puede prevenirse exigiendo que todos los procesos soliciten todos los recursos que necesiten a un mismo tiempo y bloqueado el proceso hasta que todos los recursos puedan concederse simultneamente. NO APROPIACIN. Puede prevenirse de varias formas: 1. 2. 3. Si a un proceso que retiene ciertos recursos se le niega una nueva solicitud este proceso deber liberar sus recursos anteriores y solicitar de nuevo. Si un proceso esta retenido por otro proceso, el sistema puede expulsar al segundo proceso y exigirle que libere los recursos. Evitara el interbloqueo solo si hay dos procesos que posean la misma prioridad.

CIRCULO VICIOSO Puede prevenirse definiendo una ordenacin lineal de los tipos de recursos. Si a un proceso se le han asignado recursos de tipo R, entonces solo podr realizar peticiones posteriores sobre los recursos de los tipos siguientes a R en la ordenacin.

Las estrategias de prevencin de interbloqueo solucionan el problema de interbloqueo limitando el acceso a los recursos e imponiendo restricciones a los procesos. La estrategias de deteccin de interbloqueo no limitan el acceso a los recursos ni restringe las acciones de los recursos. La comprobacin de recursos en cada solicitud tiene dos ventajas:

Conduce a una pronta deteccin. El tiempo de de comprobacin es considerable.

Una vez detectada el interbloqueo, hace falta alguna estrategia de recuperacin. Las tcnicas siguientes son posibles enfoques, enumeradas en orden creciente de sofisticacin.

1. 2. 3. 4.

Abandonar todos los procesos bloqueados. Retroceder a cada proceso interbloqueado hasta algn punto de control definido previamente y volver a ejecutar todos los procesos. Abandonar sucesivamente los procesos bloqueados hasta que dejen de haber interbloqueo. Apropiarse de recursos sucesivamente hasta que deje de haber interbloqueo.

Para el puntos 3 y 4, el criterio de seleccin podra ser uno delos siguientes, consistentes en escoger el proceso con: La menor cantidad de tiempo de procesador consumismo hasta ahora. El menor nmero de lneas de salida producidas hasta ahora. El mayor tiempo restante estimado. El menor numero total de recursos asignados hasta ahora. La prioridad mas baja.

Prediccin del interbloqueo Con prediccin del interbloqueo, se decide dinmicamente si la peticin actual de asignacin de un recurso podra, de concederse, llevar potencialmente a un interbloqueo. La prediccin del interbloqueo necesita, conocer las peticiones futuras de los recursos. Enfoques para la prediccin del interbloqueo: *No iniciar un proceso si sus demandas pueden llevar al interbloqueo. *No conceder una solicitud de incrementar los recursos de un proceso si esta asignacin puede llevar al interbloqueo.

INTRODUCCIN El Sistema Operativo tiene la tarea de asignar procesadores fsicos a los procesos, el problema al que se enfrenta es cuando asignar procesadores y a que procesos asignarlos, as como considerar la admisin de nuevas tareas y la activacin y reactivacin de procesos para ajustar la carga del sistema. NIVELES DE PLANIFICACIN Tres niveles importantes:

Planificacin de Bajo Nivel

Planificacin de Nivel Intermedio

Planificacin de Alto Nivel

Determina que trabajos pueden competir por recursos para convertirse en procesos.

Determina que procesos compite por la UCP. Asigna la UCP al proceso

CRITERIOS DE LA PLANIFICACION

Limitacin de un proceso por entrada y salida. Cuando un proceso obtiene la UCP. La Limitacin de un proceso por UCP. Cuando un proceso obtiene la UCP Si un proceso es por lotes e iterativo. Procesos iterativos suele hacer peticiones triviales las cuales deben ser atendidas inmediatamente, los procesos por lote pueden tolerar retrasos. Cuan urgente es la respuesta. Las Prioridades de los procesos. Frecuencia de fallas de un Proceso. Fallas de pagina. Frecuencia con la que los recursos de un proceso son apropiados por otro proceso de mayor prioridad. Cuanto tiempo real de ejecucin ha recibido el proceso. Cuanto tiempo mas requerir el proceso para terminar.

Planificacin Apropiativa y no Apropiativa Una disciplina de planificacin es no apropiativa si una vez que la UCP ha sido asignada al proceso, ya no se le puede arrebatar. Una disciplina de planificacin es apropiativa si al proceso se le puede arrebatar la UCP. La planificacin apropiativa es til en: Sistemas en los cuales los procesos de alta prioridad requieren una atencin rpida. En sistemas de tiempo real. Sistemas interactivos de tiempo compartido

La planificacin apropiativa es importante para garantizar tiempos de respuesta aceptables. El cambio de contexto implica un gasto extra. Para que la tcnica de apropiacin sea efectiva deben mantenerse muchos procesos en almacenamiento principal de manera que el siguiente se encuentre listo cuando quede disponible la UCP. En los sistemas no apropiativos los trabajos largos retrasan los cortos, pero el tratamiento para todos es ms justo. Los tiempos de respuesta son ms predecibles por que los procesos de alta prioridad nuevos no desplazan a los anteriores. El diseo debe evaluar minuciosamente cada mecanismo antes de implementarlo. Cronometro de intervalos o reloj de interrupciones. El sistema operativo mantiene un reloj de interrupciones o cronometro de intervalos para generar interrupciones en un futuro especfico. Luego la UCP despacha otro proceso, este mantiene el control de la UCP hasta que la libera voluntariamente, hasta que el reloj interrumpe o hasta que alguna otra interrupcin desva la atencin de la UCP. El reloj de interrupciones ayuda a garantizar los tiempos de respuesta aceptables para los usuarios interactivos, evita que el sistema quede bloqueado en un ciclo infinito y permite que los procesos respondan a eventos dependientes de de tiempo. Los procesos que deben ejecutarse peridicamente dependen del reloj de interrupciones.

PRIORIDADES Las prioridades pueden ser asignadas de forma automtica o por el sistema, pueden ser estticas o dinmicas, o hasta compradas. El sistema operativo necesita saber a que procesos dar prioridad y que procesos no le importa atender. Prioridades estticas y dinmicas. Las prioridades estticas no cambian, estos mecanismos son fciles de llevar a la prctica e implican un gasto muy bajo Los mecanismos de prioridad dinmica responden a los cambios, los esquemas de prioridad dinmica son ms complejos e implican mayor gasto. Prioridades compradas Un sistema operativo debe proporcionar un servicio competente y razonable. Cuando un usuario tiene un trabajo que es urgente puede comprar prioridad por obtener un nivel de alto servicio. TAMAO DEL CUANTO La determinacin del tamao del cuanto en vital para la operacin efectiva de un sistema de cmputo. Si el cuanto es muy grande, cada proceso tendr el tiempo necesario para terminar, de manera que el esquema de planificacin por turno degenera en uno de primeras entradas-primeras salidas. Si el cuanto es muy pequeo, el gasto extra por cambio de contexto se convierte en el factor dominante y el rendimiento del sistema se degradara hasta el punto en que la mayor parte del tiempo se invierta en la conmutacin del procesador, con muy poco o ningn tiempo para realizar clculos de los usuarios. EXACTAMENTE DNDE, ENTRE CERO E INFINITO, DEBE FIJARSE EL TAMAO DEL CUANTO? Supngase un control circular marcado con graduaciones desde q = 0 hasta q = infinito; se comienza en la posicin cero y al girar la perilla camba el cuanto del sistema. El sistema esta operando y hay muchos usuarios interactivos; al comenzar la rotacin de la perilla, las lecturas se encuentran cerca de cero y el cambio del contexto consume mayor parte del recurso de UCP (Unidad Central de Proceso). Los usuarios interactivos perciben un sistema lento con tiempos de respuesta pobres. Al girar ms la perilla y aumentar el tamao del cuanto, mejoran los tiempos de respuesta: al menos se ha alcanzado el punto en el cual el porcentaje del tiempo de UCP consumido por el trabajo extra es suficiente pequeo para que los usuarios reciban algn servicio de la UCP. No obstante, los tiempos de respuesta aun no son buenos. Y as continuamente mientras mas se gire la perilla van mejorando los tiempos de respuesta. Considrese el supuesto valor ptimo del cuanto que proporcion buenos tiempos de respuesta. Es una pequea fraccin de segundo Qu representa un cuanto? Es lo bastante grande como para que la gran mayora de las peticiones interactivas requieran menos tiempo que la duracin del cuanto. Cul es exactamente este cuanto ptimo? Vara de un sistema a otro y puede variar en presencia de diferentes cargas; tambin vara de un proceso a otro.

10.12

PLANIFICACIN POR PRIORIDAD DEL TRABAJO MS CORTO (SJF)

La planificacin por prioridad del trabajo ms corto (SJF, shortest-job-first) es una disciplina no apropiativa segn la cual se ejecuta primero el trabajo (o proceso) en espera que tiene el menor tiempo estimado de ejecucin hasta terminar. SJF reduce el tiempo de espera promedio de PEPS (Br74), pero, los tiempos de espera tienen un variacin ms grande (es decir, son ms impredecibles) que los de PEPS, sobre todo el caso de trabajos grandes. SJF selecciona trabajos para atenderlos de manera que se asegure que el siguiente trabajo se completar y saldr del sistema o antes posible. Esto tiende a reducir el nmero de trabajos en espera, y reduce tambin el nmero de los que esperan detrs de un trabajo grande. Como resultado, SJF puede reducir al mnimo el tiempo de espera promedio de los trabajos que entran en el sistema. El problema obvio con SJF es que exige conocer con exactitud el tiempo que tardar en ejecutarse un trabajo o proceso, y esa informacin no suele estar disponible; lo mejor que puede hacer SJF es basarse en los tiempos de ejecucin estimados por el usuario. En los ambientes de produccin donde se ejecutan regularmente los mismos trabajos es posible proporcionar estimaciones razonables, pero en los ambientes de desarrollo los usuarios rara vez conocen el tiempo que tardarn en ejecutarse sus programas.

PLANIFICACIN POR EL TIEMPO RESTANTE MS CORTO (SRT) En SRT el proceso con el menor tiempo estimado de ejecucin para terminar es el primero en ejecutarse incluyendo los posesos nuevos, a diferencia de SJF un proceso en ejecucin puede ser desposedo por un nuevo con menor tiempo de ejecucin estimada. SRT ofrece tiempos mnimos de espera pero debido al gasto extra de la apropiacin, es posible que SJF tenga mayor rendimiento en ciertos casos.

PLANIFICACIN POR PRIORIDAD DE LA TASA DE RESPUESTA MS ALTA (HRN) Brinch hansen desarrollo la estrategia de prioridad de la tasa de respuesta ms alta (HRN) Es una disciplina de planificacin no apropiativa en la cual la prioridad de cada trabajo no es solo funcin del tiempo de servicio, sino tambin del tiempo que ha esperado el trabajo para ser atendido. Cuando un trabajo obtiene el procesador, se ejecuta hasta terminar. La prioridad dinmica en HRN se calcula de acuerdo a la siguiente frmula: Prioridad = (tiempo de espera + tiempo de servicio) / tiempo de servicio