Embed Size (px)
Citation preview
Competencia de ProcesosDr. Alonso Ramírez Manzanares
14-Sep-2010
Comunicación entre procesos Exclusión mutua con espera activa
La instrucción TSL (Test and Set Lock)
Es una función implementada por hardware que en una operación indivisible (pone un candado al bus de memoria):
Lee el contenido de la palabra de memoria
lo coloca en un registro
y luego almacena un valor distinto de cero en esa direccion de memoria.
Para usarla declaramos una variable compartida lock que coordina el acceso a los recursos compartidos.
Comunicación entre procesos Exclusión mutua con espera activa
La instruccion TSL
Cuando lock tiene valor 0 cualquier proceso puede cambiarla a 1 con la funcion TSL, entrar en su region critica y ponerle 0 con un comando MOVE ordinario cuando libere el recurso. Usando 2 funciones en pseudo ensamblador:
Comunicación entre procesos Exclusión mutua SIN espera activa
Las 2 soluciones anteriores funcionan, el unico problema que tienen es la espera activa.
La espera activa tambien nos puede llevar al problema de inversion de prioridad:
Un proceso de alta prioridad es planificado (se le otorga el CPU) siempre en su espera activa, y un proceso de baja prioridad queda siempre fuera del CPU, pero dentro de su región critica y nunca es planificado para que pueda salir de ella, i.e., los 2 quedan bloqueados.
Comunicación entre procesos Exclusión mutua SIN espera activa
Podemos usar primitivas de comunicación entre procesos: SLEEP y WAKEUP.
SLEEP hace que el invocador se bloquee (duerma) hasta que otro proceso lo despierte.
WAKEUP tiene un parámetro que es el proceso que debe de despertar.
Comunicación entre procesos Exclusión mutua SIN espera activa
El problema del productor-consumidor o del buffer limitado.
El productor quiere depositar en un buffer lleno, entonces deberia de dormirse hasta que haya espacio.
El consumidor quiere sacar datos de un bufer vacio, entonces debiera de dormirse hasta que haya datos.
Escencialmente tenemos el mismo problema de competencia que con el spooler de impresión.
Comunicación entre procesos Exclusión mutua SIN espera activa
El problema del productor-consumidor Para poder dar seguimiento, usamos la variable count que indica el # de elementos en el buffer con capacidad máxima N.
Comunicación entre procesos Exclusión mutua SIN espera activa
El problema del productor-consumidor Para poder dar seguimiento, usamos la variable count que indica el # de elementos en el buffer con capacidad máxima N.
Tenemos un problema de competencia porque la variable count no tiene acceso restringido.
El problema del productor-consumidor, ejemplo de un problema:
El buffer esta vacio
El consumidor lo verifica
Sale el consumidor de CPU y entra productor
Este produce, incrementa count, ve que es 1 (supone que antes era 0) y emite señal de despertar que se pierde.
El consumir reanuda su ejecución y se duerme dado que su valor leído es 0.
El productor llena el buffer y se duerme, y todos quedan dormidos.
Comunicación entre procesos Exclusión mutua SIN espera activa
Comunicación entre procesos Exclusión mutua SIN espera activa
El problema en el enfoque anterior es que la señal de despertar se perdió. Si no se hubiera perdido, todo hubiera funcionado.
Una compostura rápida (parche) es usar un bit que se prende cuando se intenta despertar a un proceso despierto, el cual cuando intenta dormirse lo verifica, lo apaga y se mantiene despierto. Pero esto no va a funcionar para 3 procesos o n procesos.
Comunicación entre procesos Exclusión mutua SIN espera activa
Lo anterior lo podemos corregir con semáforos.
SemáforosDijkstra propuso usar un nuevo tipo de variable entera para contar el numero de señales de despertar para uso futuro.
Esta variable tiene asociada 2 operaciones DOWN y UP (que son generalizaciones de SLEEP y WAKEUP respectivamente).
La operación DOWN (aplicada a un semáforo) verifica si es mayor que 0, si es es así, la decrementa en uno (gasta una señal de WAKEUP almacenada) y continúa. De lo contrario el proceso invocador se pone a dormir sin completar el DOWN por el momento.
SemáforosLa verificación de valor su modificación y la acción de dormirse (si es necesario) se realiza en una sola acción atómica indivisible. Es decir, se garantiza que una vez que una operación de semáforo se ha iniciado ningún otro proceso podrá acceder al semáforo.
La operación UP incrementa el valor del semáforo direccionado enviando una señal asociada a dicho semáforo. Si uno o mas procesos estaban bloqueados con respecto a este semáforo, el sistema escoje alguno de ellos (al azar) y le permite completar su DOWN.
La operación de incrementar el semáforo y despertar UN proceso también es indivisible.
SemáforosNótese que después de una llamada a UP con el semáforo en 0 y con procesos esperando el semáforo seguirá siendo 0 pero abrá un proceso menos esperando.
Normalmente se implementa DOWN y UP como llamadas al SO, de tal forma que este inhabilita las interrupciones momentaneamente mientras prueba, actualiza y pone un proceso a dormir (es un TSL). Al ser hecho por el SO y tomar pocos microsegundos (solo la espera de acceder el semáforo) no hay problema.
Si tenemos muchas CPU cada semáforo debe de estar protegido por un candado de bus (como en la instruccion TSL), con la cual no más de 1 CPU puede examinar el semáforo a la vez.
El problema del productor consumidor con semáforos
3 semáforos: full, empty (contadores) y mutex (semáforo binario).
El problema del productor consumidor con semáforos
El problema del productor consumidor con semáforos
Entonces el semáforo mutex garantiza exclusión mutua. Protege el uso de las variables compartidas del buffer.
Los otros 2 semáforos son de sincronización: aseguran que el consumidor se va a bloquear cuando el buffer está vacio, etc.
¿Cómo funcionaba el planificador?: Semáforos
Resumiendo:Aqui se hace un UP a un semáforo (el proceso que lo admistra inicialmente
hace un DOWN)
MonitoresExiste un problema con los semaforos, ¿qué pasa si por error intercambiamos el orden de estos semáforos?
mutex se decrementa antes que empty.Si el buffer está lleno el productor se bloquea con mutex
puesto en 0, cuando el consumidor quiera accesar el buffer, se va a bloquear y ambos quedan en bloqueo mutuo para
siempre (¡¡esto es responsabilidad del programador!!).
MonitoresA fin de facilitar la escritura de programas correctos se propuso una primitiva de sincronización de mas alto nivel llamada monitor.
Es una colección (o paquetes especial) de procedimientos variables y estructuras.
Los procesos pueden invocar los procedimientos del monitos en el momento que deseen, pero no pueden acceder a las estructuras de datos internas del monitor.
Y SOLO UN PROCESO PUEDE ESTAR ACTIVO EN UN MONITOR EN UN MOMENTO DADO.
MonitoresEjemplo:
El compilador sabe que es una estructura especial:
MonitoresDe tal forma que cuando un proceso invoca a un procedimiento de monitor, las primeras isntrucciones del procedimiento verifican si existe algun otro proceso activo en ese momento dentro del monitor. Si es así, el proceso invocador se suspende hasta que el otro proceso abandona el monitor.
La exclusion multiple se implementa por lo general con un semáforo binario. Pero de esto se encarga el compilador y no el usuario.
Ya tenemos garantizada la exclusion mutua, pero ahora necesitamos sincronizacion.
MonitoresPara eso agregamos las señales:
WAIT: se ejecuta cuando un procedimiento de monitor descubre que no puede continuar, con alguna variable de condición (por ejemplo full). Esto hace que el proceso invocador se bloquee y asi permite que otro proceso entre al monitor.
SIGNAL sejecuta para despertar procesos que estan en espera con respecto a una variable de condición (por ejemplo full). Para evitar que 2 procesos esten adentro del monitor (despertador y despertado) al mismo tiempo, el proceso que ejecutó signal debe de salir inmediatamente del monitor, es decir debe de ser su última instrucción.
Monitores
Las variables de condición no son acumuladores. Por lo tanto una señal SIGNAL se puede perder. Por lo tanto la señal WAIT tiene que venir siempre antes que SIGNAL. Esta regla simplifica la implementación.
Implementación de Monitores
Implementación de Monitores
Implementación de Monitores
Diferencia: aqui no puede haber interrupción
