sistemas operativos temas 4, 5 y 6idtv.det.uvigo.es/~jgd/so/diapositivas/4.pdf · 2011-01-31 ·...

Sistemas Operativos. 2009-2010

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

Sistemas Operativos. 2009-2010

Í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.

Sistemas Operativos. 2009-2010 Herramientas de Sincronización de Alto Nivel

Tema 4. Herramientas de Sincronización de Alto

Nivel


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.


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;


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.


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;


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--; }


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.


Monitores(I). Introducción

DATOS

S I N C.

S I N C.

S I N C.

S I N C.

Monitor: tipo abstracto de datos que garantiza el acceso en exclusión mutua a los datos.

Proceso B Proceso A

• Objetivo: aislar el código de sincronización del código de los procesos.


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.

DATOS

Internas f1

f2

f6 f3

f5

f4

Inicio()


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)


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(); }


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.


DATOS

Internas

Cola de Procesos de Entrada

Colas de Variables de Condición Cola Interna

Inicio()

MONITOR


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);


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);

sistemas operativos temas 4, 5 y 6idtv.det.uvigo.es/~jgd/so/diapositivas/4.pdf · 2011-01-31 ·...

Documents