Tema 3: Concurrencia de procesos
Yolanda Blanco Fernndez
[email protected] Concurrencia, Tiempo Real y Paralelismo
Concurrencia: Convivencia de un conjunto de procesos en un mismo ordenador. Sistemas de tiempo real: Limitados por restricciones temporales crticas. Para vencerlas, los sistemas de tiempo real suelen ser concurrentes. Paralelismo: Posibilidad de ejecutar varias sentencias simultneamente en un mismo ordenador precisan varios procesadores concurrencia. Vamos a trabajar con monoprocesadores.
Curso 2009/2010
Grafos de Precedencia
Representacin grca de un algoritmo en el que se establece el orden de ejecucin de un conjunto de instrucciones y/o datos.
I1 I1
I2
I2
I4
I5 I3 I3 I7 I6
Algoritmo secuencial
Algoritmo concurrente
Los procesos concurrentes de un algoritmo pueden ser independientes o compartir datos. Nuestro objetivo: estudiar ambos tipos de relaciones entre procesos concurrentes, mediante soluciones independientes del procesador y su algoritmo de planicacin.
Curso 2009/2010
Construcciones FORK y JOIN (Longway)
Fork <etiqueta> Divide el ujo en 2 procesos: el que viene despus de Fork, y el que viene despus de la etiqueta. Join <contador >: Espera hasta que acaben los contador procesos que debe unir antes de seguir la ejecucin. Ejemplo 1:
I0
I1
I2
I3
contador = 2; I0 ; F ORK L1 I1 ; GOT O L2 ; L1 : I2 ; L2 : JOIN contador; I3 ;
Curso 2009/2010
Construcciones FORK y JOIN (II)
Ejemplo 2: contador = 3; I0 ; F ORK L1 ; I1 ; GOT O L2 ; L1 : F ORK L3 ; I2 ; GOT O L2 ; L3 : I3 ; L2 : JOIN contador; I4 ;
I0
I1
I2
I3
I4
Problemas: El uso de GOT O perjudica la legibilidad del programa. No empleado en lenguajes de alto nivel. Difcil depuracin etiquetas. Alternativa: Sentencias COBEGIN y COEND.
Curso 2009/2010
Construcciones COBEGIN y COEND (Dijkstra)
Tambin denominadas PARBEGIN y PAREND. COEND cierra tantas ramas como haya abierto COBEGIN. Ejemplo: I I0 ; COBEGIN I1 , I2 , . . . , IN ; I I I COEN D; IN +1 ; I
0 1 2 N N+1
Ejercicio #1: Implementar el siguiente grafo con: (i) sentencias FORK y JOIN y (ii) sentencias COBEGIN y COEND.
S1
S2
S3
S4
S5
S6
S7
Curso 2009/2010
Construcciones COBEGIN y COEND (II)
Fcil incorporacin en lenguajes de alto nivel. Depuracin ms sencilla que FORK y JOIN. Equivalencia entre FORK-JOIN y COBEGIN-COEND? Ejercicio #2: Escribir el siguiente grafo con sentencias FORK-JOIN y COBEGIN-COEND.
S1 S2 S3
S4
S5
S6
S7
NO son equivalentes. En UNIX: fork(), execl(), wait() y waitpid(PID).
Curso 2009/2010
Procesos Concurrentes que comparten Datos
Al compartir datos entre procesos se pueden producir problemas de indeterminismo (resultados diferentes segn escenario de prueba). Ejemplo: S1 y S2 no son independientes, sino que comparten la variable x.
S0
S1
S2
S3
S0 : x = 100; S1 : x := x + 10; S2 : if x > 100 then write(x); else write (x 50); S3 : nop;
Escenario #1: S1 y S2 Se escribe x = 110. Escenario #2: S2 y S1 Se escribe x = 50. Escenario #3: S2 pierde el control (p. ej. n de quantum) antes de escribir y sigue S1 Se escribe x = 60. Se han propuesto mltiples soluciones para tratar situaciones indeterministas con procesos concurrentes compartiendo datos.
Curso 2009/2010
Solucin de Bernstein
Cada proceso Pi est asociado a dos conjuntos: R(Pi ): conjunto de variables accedidas durante la ejecucin de Pi . W (Pi ): conjunto de variables modicadas durante la ejecucin de Pi . Bernstein concluy que para que dos procesos Pi y Pj , concurrentes, puedan ejecutarse de forma determinista tienen que satisfacerse las siguientes condiciones: R(Pi ) W (Pj ) = W (Pi ) R(Pj ) = W (Pi ) W (Pj ) = Condiciones sucientes pero no necesarias slo se pueden compartir variables de lectura. Objetivo: Buscar soluciones al indeterminismo sin que se cumplan las condiciones de Bernstein compartir variables de escritura.
Curso 2009/2010
Seccin Crtica
Ejemplo de motivacin: contar el nmero de coches que pasan por los dos carriles de una autopista. El problema surge cuando los procesos-contadores intentan acceder a una variable compartida. Seccin crtica: zona de cdigo de un proceso en la cual se lee y/o modican las variables compartidas por los procesos concurrentes. Solucin: exclusin mutua cuando un proceso est en su seccin crtica, ningn otro puede estar en la suya. Para ello, adoptaremos las restricciones de Djkstra: La solucin debe ser independiente del HW o del nmero de procesos. No se puede realizar ninguna suposicin sobre la velocidad relativa de los procesos. Cuando un proceso est fuera de su seccin crtica no puede impedir a otros procesos entrar en sus respectivas secciones crticas. La seleccin del proceso que debe entrar en la seccin crtica no puede posponerse indenidamente. Puede producirse interbloqueo: procesos bloqueados que slo podran ser desbloqueados por otros que tambin estn en bloqueo.
Curso 2009/2010
Posibles Soluciones al Contador de Coches
1. Asociar una variable booleana libre al acceso al recurso comn (la seccin crtica). El proceso accede si libre=TRUE. No sirve porque si se pierde el control en libre=FALSE, los dos procesos accedern a la vez al recurso indeterminismo!! Un proceso pasa cuando libre=TRUE y el otro cuando libre=FALSE. Slo funciona si la velocidad de ambos procesos est acompasada: si pasan dos coches por el carril izquierdo, slo se podr contar el segundo cuando pase un coche por el carril derecho (y ponga libre=TRUE). Solucin invlida por violar la tercera restriccin de Djkstra: un proceso impide que otro acceda a la seccin crtica cuando no la est usando. Si el segundo proceso quiere acceder a la seccin crtica, le dejamos; en caso contrario, accede el primer proceso. Se garantiza exclusin mutua. Es posible que los dos procesos se den el turno el uno al otro y ninguno acceda al recurso comn se viola 4a restriccin Djkstra. La solucin vlida es el algoritmo de Dekker.
Curso 2009/2010
2.
3.
4.
Algoritmo de Dekker
Curso 2009/2010
Conclusiones
Las soluciones son mucho ms complejas de lo que parecen a simple vista. Incluso en el algoritmo de Dekker la sincronizacin se consigue siempre mediante espera activa (esperar por una condicin comprobndola continuamente) despilfarro de recursos. La programacin concurrente tiene que ser sistemtica Demasiados escenarios de prueba para ingenieros SW. Es necesario recurrir a herramientas de programacin ms potentes herramientas de sincronizacin: Herramientas de bajo nivel. Herramientas de nivel intermedio: semforos. Herramientas de alto nivel: regiones crticas y monitores.
Curso 2009/2010
Herramientas de Sincronizacin
Funciones primitivas, implementadas de forma SW o HW, que ayudan a controlar la interaccin entre procesos concurrentes: Sincronizacin: Los procesos intercambian seales que controlan su avance. Comunicacin: Los procesos intercambian informacin. Caractersticas deseables: Desde el punto de vista conceptual: Simplicidad. Generalidad. Vericabilidad. Desde el punto de vista de implementacin: Eciencia. Tipos de herramientas de sincronizacin: Nivel HW: acceso a recursos HW compartidos asegurando uso en exclusin mutua (por ejemplo, memoria y buses). Nivel SW: LOCK/UNLOCK, TEST-AND-SET, SWAP.
Curso 2009/2010
Primitivas LOCK/UNLOCK, TEST-AND-SET y SWAP
Deben ejecutarse de forma indivisible. LOCK bloquea el acceso a la variable comn y UNLOCK lo desbloquea. TEST-AND-SET devuelve el valor de la variable comn y la pone a TRUE (para bloquearla). SWAP (var a, b: BOOLEAN) intercambia el valor de a por b y de b por a. Conclusiones: Consiguen soluciones ms sencillas que la propuesta por Dekker. Solucin generalizable a N procesos. Principal inconveniente: No se elimina la espera activa. Las herramientas de sincronizacin de bajo nivel no se usan en aplicaciones concurrentes. Son la base para las herramientas de alto nivel.
Curso 2009/2010
Los Semforos
Objetivo: solucin al problema de la exclusin mutua evitando la espera activa (Dijkstra, 1965). Un semforo sem consta de tres partes: Una variable entera interna (s) con un valor mximo N (no accesible para los procesos). Una cola de procesos (no accesible para los procesos). Dos funciones bsicas de acceso: wait(sem): si s < 0, el proceso se suspende en la cola asociada al semforo. signal(sem): si hay algn proceso suspendido en la cola asociada al semforo, se despierta al ms prioritario; en caso contrario, se incrementa en una unidad el valor de s (sin superar el valor mximo N ).
Curso 2009/2010
Implementacin de WAIT y SIGNAL
WAIT(s): s := s 1 if s < 0 then begin estado-proceso = espera; poner-proceso-en-cola_espera_semforo; end; SIGNAL(s): s := s + 1 if s 0 then begin poner-proceso-en-cola_preparados; estado-proceso = activo; end; Si s 0 se bloquean todos los procesos; si s 1 no exclusin mutua. El valor inicial y mximo de la variable s determinan la funcionalidad del semforo.
Curso 2009/2010
Semforos de Exclusin Mutua
Semforos binarios: la variable interna s slo puede tomar los valores 0 y 1. Solucin al problema de la exclusin mutua: Un semforo binario con s = 1. Antes de acceder a la seccin crtica el proceso ejecuta wait(sem). Al nalizar la seccin crtica el proceso ejecuta signal(sem).
Curso 2009/2010
Semforos de Paso
Permiten implementar grafos de precedencia. Para cada punto de sincronizacin entre dos procesos: semforo binario con s = 0. El proceso que debe esperar ejecuta wait(sem). Al alcanzar un punto de sincronizacin el otro proceso ejecuta signal(sem).
Curso 2009/2010
Semforos Enteros y de Condicin
N procesos accediendo a la seccin crtica: Semforo con s = N , siendo N el valor mximo permitido. Antes de acceder a la seccin crtica el proceso ejecuta wait(sem). Al nalizar la seccin crtica el proceso ejecuta signal(sem).
Sincronizacin entre procesos en funcin de una variable entera: Semforo cuya variable s est inicializada a N 0 (siendo N el valor mximo). El proceso que debe esperar ejecuta wait(sem). Al alcanzar un punto de sincronizacin el otro proceso ejecuta signal(sem). Ejemplo clsico: problema del productor-consumidor (con bfer limitado e ilimitado).
Curso 2009/2010
Problema del Producto-Consumidor
Seccin crtica del productor (P) y del consumidor (C): acceso al bfer. Condiciones: P produce si bfer no lleno y C consume si bfer no vaco. Solucin con bfer ilimitado (prob [bfer lleno] 0) El consumidor slo acceder al bfer cuando haya algn dato que consumir. Solucin con bfer limitado El productor slo volcar dato en bfer si hay sitio y consumidor slo acceder si hay algn dato que consumir.
Curso 2009/2010
Solucin del Producto-Consumidor con Bfer Ilimitado
PROCEDURE P; BEGIN REPEAT Producir_Dato; WAIT(s); Dejar_Dato_en_Buffer; SIGNAL(s); SIGNAL(vacio); FOREVER; END; PROCEDURE C; BEGIN REPEAT WAIT(vacio); WAIT(s); Extraer_Dato_del_Buffer; SIGNAL(s); Consumir_Dato; FOREVER; END; Curso 2009/2010
PROGRAM P-C; VAR buffer: ARRAY [N] of datos; s: SEMAFORO //en exclusin mutua vacio: SEMAFORO //de condicin BEGIN s=1; vacio=0; COBEGIN P; C; COEND END
Solucin del Producto-Consumidor con Bfer Limitado (tamao N)
PROCEDURE P; BEGIN REPEAT Producir_Dato; WAIT(lleno); WAIT(s); Dejar_Dato_en_Buffer; SIGNAL(s); SIGNAL(vacio); FOREVER; END; PROCEDURE C; BEGIN REPEAT WAIT(vacio); WAIT(s); Extraer_Dato_del_Buffer; SIGNAL(s); SIGNAL(lleno); Consumir_Dato; Curso 2009/2010
PROGRAM P-C; VAR buffer: ARRAY [N] of datos; s: SEMAFORO //en exclusin mutua vacio, lleno: SEMAFORO //de condicin BEGIN s=1; // exclusin mutua vacio=0; //de condicin lleno=N; //de condicin COBEGIN P; C; COEND END
Problema de la Cena de los Filsofos
Arroz
Los lsofos cogen 2 palillos, se echan arroz del plato, comen y dejan los palillos. Suponemos que el arroz no se acaba nunca y que cada lsofo slo puede coger los palillos de los compaeros que tiene a ambos lados. Recurso compartido: los palillos.
Curso 2009/2010
Solucin vlida? al Problema de los Filsofos
PROCEDURE FILOSOFO[i]; BEGIN REPEAT Pensar; WAIT(palillos[i]); WAIT(palillos[i+1 mod 5]); Servirse_y_comer; SIGNAL(palillos[i]); SIGNAL(palillos[i+1 mod 5]); FOREVER; END;
PROGRAM CENA-FILOSOFOS; VAR palillos: ARRAY [0:4] of SEMAFORO; BEGIN for i=0:4 palillos[i]=1; // exclusin mutua COBEGIN for i=0:4 FILOSOFO[i]; COEND END
Un bloque de varios WAIT no es indivisible; un solo WAIT s lo es. Solucin invlida: 5 lsofos pueden bloquear un solo palillo y nadie come! Solucin correcta: comedor virtual con 4 comensales (1 lsofo siempre come). Semforos utilizados: en exclusin mutua (palillos, incializados a 1) y de condicin (comedor, inicializado a 4).
Curso 2009/2010
Conclusiones
Ventajas: Mecanismo seguro de acceso a recurso compartido mediante encapsulamiento de las operaciones sobre la variable que controla el semforo. Consiguen sincronizacin de procesos concurrentes evitando la espera activa. El programa principal debe inicializar el semforo (segn su uso). Inconvenientes: La inicializacin es crtica, as como confundir un wait con un signal u omitir alguno de ellos. Resultan programas muy grandes y complejos, difciles de depurar. Soluciones alternativas: regiones crticas y monitores.
Curso 2009/2010
Yolanda Blanco Fernndez [email protected] Lab. B-203
Curso 2009/2010
