Sistemas Operativos Temas 4, 5 y 6. Jorge García Duque Despacho: B-202 Tutorías: Lunes 16:00-18:00 y Martes 16:00-20:00

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Sistemas Operativos Temas 4, 5 y 6. Jorge García Duque Despacho: B-202 Tutorías: Lunes 16:00-18:00 y Martes 16:00-20:00"

Transcripción

1 Sistemas Operativos Temas 4, 5 y 6 Jorge García Duque Despacho: B-202 Tutorías: Lunes 16:00-18:00 y Martes 16:00-20:00

2 Índice Tema 4: Herramientas de Sincronización de Alto Nivel. Regiones Críticas. Monitores. Tema 5: Comunicación entre procesos. Tema 6: Gestión de Interbloqueo Resolución de cuestiones y problemas de examen.

3 Tema 4. Herramientas de Sincronización de Alto Nivel

4 Regiones Críticas (I). Introducción Objetivo: evitar los problemas de inicialización y errores en la disposición de las sentencias wait y signal. Consta de una variable compartida x de cualquier tipo, a la que sólo se puede acceder mediante la sentencia: REGION x DO S, donde S es la sección crítica donde se accede a la variable x. La Región Crítica garantiza el acceso en exclusión mutua a S, y por tanto, a los datos contenidos en la variable x.

5 Regiones Críticas (II). Exclusión Mutua Proceso P { Proceso Q { shared tipo x; shared tipo x; REGION x DO BEGIN REGION x DO BEGIN Sección Crítica; Sección Crítica; END; END; } } COBEGIN P;Q; COEND;

6 Regiones Críticas (III). Exclusión Mutua Implementación con semáforos: La sentencia shared tipo x se sustituye por: semaforo x_mutex(1); La sentencia REGION x DO S se sustituye por: wait(x_mutex); S; signal(x_mutex); Problema: sólo solucionamos el problema de la exclusión mutua.

7 Regiones Críticas (IV). Condicionales Regiones Críticas Condicionales: Se añade una condición de acceso booleana B: REGION x WHEN B DO S; Sólo si B es cierto se compite por el acceso en exclusión mutua a S. Si B es falso, el proceso se suspende hasta que B sea cierto y pueda competir por la exclusión mutua. La comprobación de B debe hacerse en exclusión mutua por lo que sus variables involucradas deben incluirse en la Región x;

8 Regiones Críticas (V). Implementación [shared tipo x]: semaforo x_mutex(1), x_wait(0); int x_cuenta = 0, x_temp = 0; [REGION x WHEN B DO S]: wait(x_mutex); if (NOT B) { x_cuenta++; signal(x_mutex); wait(x_wait); while (NOT B) { x_temp++; if (x_temp < x_cuenta) signal(x_wait); else signal(x_mutex); wait(x_wait); } x_cuenta--; }

9 Regiones Críticas (VI). Implementación [REGION x WHEN B DO S] (cont): S; if (x_cuenta > 0) { x_temp = 0; signal(x_wait); } else signal(x_mutex); Problemas de la implementación: Conlleva evaluar todas las condiciones B cada vez que un proceso accede a la sección crítica. Los procesos se desordenan.

10 Monitores(I). Introducción Objetivo: aislar el código de sincronización del código de los procesos. S S S S Proceso A I N I N DATOS I N I N Proceso B C. C. C. C. Monitor: tipo abstracto de datos que garantiza el acceso en exclusión mutua a los datos.

11 Monitores(II). Introducción Sólo un proceso puede ejecutar simultánemente una de las funciones de acceso (ENTRY) definidas para el Monitor. El Monitor puede incluir funciones internas con el objetivo de estructurar la codificación de las funciones de acceso. Los procesos no pueden acceder a las funciones internas ni a los datos del Monitor. f1 Internas f4 f2 DATOS f5 f3 Inicio() f6

12 Monitores (III). Condicionales Se incluyen como parte de los datos del Monitor Variables de Condición: Una variable de condición v consta de: Una cola de procesos. Tres funciones de acceso: wait(v): suspende al proceso en la cola asociada a la variable de condición. signal(v): si existe algún proceso suspendido en la cola asociada a la variable de condición se despierta el más prioritario. empty(v): función boolena que retorna verdadero si no existe ningún proceso suspendido en la cola asociada a la variable de condición (falso en caso contrario)

13 Monitores(IV). Condicionales Monitor Semaforo inicio() { int s; s = N; condition v; } ENTRY wait() { ENTRY signal() { if (s == 0) wait(v); if (empty(v)) s++; else s--; else signal(v); } } Proceso P { M.wait(); S; M.signal(); }

14 Monitores (V). Condicionales Problema: cuando un proceso P despierta a otro proceso Q suspendido sobre una variable de condición, existirán dos procesos preparados dentro del Monitor!. Solución: como el Monitor garantiza la exclusión mutua en el acceso a los datos, uno de los dos procesos se suspenderá hasta que el otro abandone el Monitor (retorna o se suspende sobre una variable de condición). Dos posibilidades: 1. Continúa el proceso señalado (Q) y se demora el que ha ejecutado el signal (P). 2. Continúa el proceso que ha ejecutado el signal (P) y se demora el proceso señalado (Q). En general, las soluciones son dependientes del tipo de Monitor. Soluciones independientes del tipo de Monitor: después de un signal, el proceso abandona el Monitor.

15 Colas de Variables de Condición Cola Interna MONITOR Internas DATOS Inicio() Cola de Procesos de Entrada

16 Monitores(VI). Implementación semaforo mutex(1), next(0); int next_count = 0; [condition v]: semaforo v_sem(0); int v_count = 0; [Monitor.f()]: wait(mutex); if (next_count > 0) f(); signal(next); siguiente(); else signal(mutex);

17 Monitores(VII). Implementación [signal(v)]: Tipo 1 (cont. señalado) if (v_count > 0) { next_count++; signal(v_sem); wait(next); next_count--; } [wait(v)]: Tipo 1 (cont. Señalado) v_count++; siguiente(); if (next_count > 0) wait(v_sem); signal(next); v_count--; else signal(mutex);