Conceptos de la clase anterior

Presentación del tema: "Conceptos de la clase anterior"— Transcripción de la presentación:

1 Conceptos de la clase anterior
Especificar la concurrencia es esencialmente especificar los procesos concurrentes, su comunicación y sincronización. Sincronizar => Combinar acciones atómicas de grano fino (fine-grained) en acciones (compuestas) de grano grueso (coarse grained) que den la exclusión mutua. Sincronizar=> Demorar un proceso hasta que el estado de programa satisfaga algún predicado (por condición). Programación Concurrente Clase 2

2 Propiedades de programas concurrentes
Una propiedad de un programa concurrente es un atributo que resulta verdadero para cualquiera de los threads de ejecución del mismo. Toda propiedad puede ser formulada en términos de dos clases de propiedades: seguridad y vida. La clase de propiedades de “seguridad” se refiere a la NO ocurrencia de eventos “malos”. Por ejemplo son clásicas las propiedades de seguridad ausencia de deadlock y ausencia de interferencia (exclusión mútua) entre procesos. Programación Concurrente Clase 2

3 Propiedades de programas concurrentes
La clase de propiedades de “vida” se refiere a la posibilidad de ocurrencia de eventos “buenos”. Por ejemplo son clásicas: asegurar que un pedido de servicio será atendido, asegurar que un mensaje llega a destino, que un proceso eventualmente alcanzará su sección crítica... dependen de las políticas de scheduling. Una política de scheduling puede ser “fair”, “por prioridades”, “estática”, “dinámica”, “jerárquica”... Programación Concurrente Clase 2

4 Propiedades de procesos concurrentes
Fairness: trata de garantizar que los procesos tengan chance de avanzar, sin importar lo que hagan los demás. A largo plazo, en multiprocesamiento, una propiedad derivada de fairness es el balance de carga entre los procesadores. Una acción atómica en un proceso es elegible, si es la próxima acción atómica habilitada en el proceso que tiene el control de ejecución. Si hay varios procesos, puede haber varias acciones atómicas elegibles  La política de scheduling determina cuál será la próxima en ejecutarse Programación Concurrente Clase 2

5 Propiedades de procesos concurrentes
Fairness Incondicional. Una política de scheduling es incondicionalmente fair si toda acción atómica incondicional que es elegible eventualmente es ejecutada. Fairness Débil. Una política de scheduling es débilmente fair si es incondicionalmente fair y toda acción atómica condicional que se vuelve elegible eventualmente es ejecutada si su guarda se convierte en true y de allí en adelante permanece true. No es suficiente para asegurar que cualquier sentencia await elegible eventualmente se ejecuta: la guarda podría cambiar el valor (de false a true y nuevamente a false) mientras un proceso está demorado. (Recordar el caso de lectores-escritores de ADA) Programación Concurrente Clase 2

6 Propiedades de procesos concurrentes
Fairness Fuerte: Una política de scheduling es fuertemente fair si es incondicionalmente fair y toda acción atómica condicional que se vuelve elegible eventualmente es ejecutada pues su guarda se convierte en true con infinita frecuencia. Relacionar lo anterior con los esquemas de scheduling que tienen “memoria”para favorecer a los procesos retrasados y lograr fairness:  Prioridades dinámicas. Programación Concurrente Clase 2

7 Especificación de la sincronización.
Sincronización por condición   await B  Ejemplo:  await count > 0  No es trivial implementar el await en procesadores reales. await B puede ser implementado como busy waiting o spinning: do (not B)  skip od Acción atómica incondicional  no contiene una condición B Acción atómica condicional  sentencia await con guarda B Programación Concurrente Clase 2

8 Sincronización por variables compartidas
busy waiting  un proceso chequea repetidamente una condición hasta que es verdadera Ventaja: implementación con instrucciones de cualquier procesador. Ineficiente en multiprogramación Aceptable si cada proceso se ejecuta en su procesador Programación Concurrente Clase 2

9 Sincronización por variables compartidas Sección Crítica
P[i:1..n] :: do true  entry protocol critical section exit protocol non-critical section od Qué deben satisfacer los protocolos de entrada y salida?? Programación Concurrente Clase 2

10 Protocolos de Entrada/Salida a la Sección Crítica. Qué deben satisfacer?
Exclusión mutua: A lo sumo un proceso está en su SC. Ausencia de Deadlock: Si dos o más procesos tratan de entrar a sus SC, al menos uno tendrá éxito. Ausencia de Demora Innecesaria: Si un proceso trata de entrar a su SC y los otros están en sus SNC o terminaron, el primero no está impedido de entrar a su SC. Eventual Entrada: Un proceso que intenta entrar a su SC tiene posibilidades de hacerlo (eventualmente lo hará). Relacionar con las guardas en los protocolos. Ejemplos. Programación Concurrente Clase 2

11 Sincronización por Sección Crítica con variables adicionales
var in1 := false, in2 := false { MUTEX: (in1  in2) debiera mantenerse invariante} P1 :: do true  in1 := true # entry protocol critical section in1 := false # exit protocol non-critical section od P2 :: do true  in2 := true # entry protocol in2 := false # exit protocol El protocolo utilizado NO asegura el invariante MUTEX Programación Concurrente Clase 2

12 Sincronización por Sección Crítica
MUTEX invariante--->fortalecer los entry protocol: var in1 := false, in2 := false { MUTEX: (in1  in2) } P1 :: do true   await not in2  in1 := true  # entry protocol critical section in1 := false # exit protocol non-critical section od Programación Concurrente Clase 2

13 Sincronización por Sección Crítica
MUTEX invariante--->fortalecer los entry protocol: var in1 := false, in2 := false { MUTEX: (in1  in2) } P2 :: do true   await not in1  in2 := true  # entry protocol critical section in2 := false # exit protocol non-critical section od Programación Concurrente Clase 2

14 Sincronización por SC  Cumple las propiedades pedidas ??
Exclusión mutua: Por construcción P1 y P2 se excluyen en el acceso a la sección crítica. Ausencia de deadlock: La situación de deadlock se podría dar con In1 e In2 verdaderas al mismo tiempo. Pero este caso NO puede darse ya que al ingresar un proceso en la sección crítica debe salir poniendo su In en FALSE, lo que libera el acceso del otro proceso. Programación Concurrente Clase 2

15 Sincronización por SC  Cumple las propiedades pedidas ??
Ausencia de demora innecesaria: Si P1 está fuera de su SC o terminó, in1 es false. Si P2 está tratando de entrar a su SC pero no puede, la guarda en su entry protocol debe ser falsa:  in1  in1 = FALSE  no hay demora innecesaria Programación Concurrente Clase 2

16 Sincronización por SC  Cumple las propiedades pedidas ??
Posibilidad de Acceso a la Sección Crítica: Si P1 está tratando de entrar y no puede, P2 está en SC e in2 es TRUE. Como un proceso que está en SC eventualmente sale, in2 será FALSE y la guarda de P1 verdadera. Análogamente con P2 Si los procesos corren en procesadores iguales y el tiempo de acceso a la SC es finito podemos afirmar que las guardas se ponen en TRUE con infinita frecuencia, lo que significa una política de scheduling fuertemente fair. Programación Concurrente Clase 2

17 Sincronización por Sección Crítica. Cambio de variables
Si lock = In1 v In2 podemos utilizar una sóla variable: var lock:= false P1 :: do true   await not lock  lock := true  # entry protocol critical section lock:= false # exit protocol non-critical section od P2 :: do true   await not lock  lock:= true  # entry protocol critical section lock := false # exit protocol non-critical section od Notar que P1 y P2 quedan idénticos. Programación Concurrente Clase 2

18 Sincronización por Sección Crítica. Una solución de grano fino.
Tenemos que lograr hacer “atómico” el AWAIT de grano grueso. Para esto se utilizan instrucciones como Test&Set (TS), Fetch&Add o Compare&Swap. En TS se tienen dos argumentos booleanos: una variable compartida lock y un código de condición local, cc Programación Concurrente Clase 2

19 Sincronización por Sección Crítica. Una solución de grano fino.
TS(lock,cc):  cc := lock; lock := true  TS devuelve el CC (código de condición) Notar el efecto sobre cada proceso Pi que ejecuta TS (testea CC) Utilizando Test&Set las 4 propiedades se pueden cumplir, y cada proceso (ver la solución que sigue) queda “dando vueltas” hasta que lock lo habilita> Spin Locks Programación Concurrente Clase 2

20 Sincronización por Sección Crítica. Una solución de grano fino con TS.
var lock:= false P1 ::var cc:bool do true  TS (lock, cc) # entry protocol do cc--> TS (lock, cc) od # entry protocol critical section lock:= false # exit protocol non-critical section od P2 :: Idéntico a P1 Notar que cuando un proceso entra en el loop, sólo sale con lock en FALSE (puesto por el otro). Si ambos quieren entrar “gana” el primero que ejecutó el TS (CC queda en FALSE y lock en TRUE.) Programación Concurrente Clase 2

21 Spin locks: Comentarios.
Baja performance en multiprocesadores si varios procesos compiten por el acceso. lock es una variable compartida y su acceso continuo es muy costoso. (“memory contention”) TS escribe en siempre en lock, aunque el valor de lock no cambie  costo en tiempo. Puede reducirse usando una lectura de lock en lugar del Test&Set: do lock  skip od # spin mientras lock está seteado TS(lock,cc) Programación Concurrente Clase 2

22 Implementación de las instrucciones AWAIT
Cualquier solución al problema de la SC se puede usar para implementar una acción atómica incondicional  S  SC Enter #protocolo de entrada a la SC S SC Exit #protocolo de salida de la SC Para implementar una acción atómica condicional await B  S: SC Enter do not B  SC Exit; SC Enter od S SC Exit Programación Concurrente Clase 2

23 Implementación de las instrucciones AWAIT
Es correcto pero ineficiente (memory contention) = mejor SC Enter do not B  SC Exit; Delay; SC Enter od S SC Exit Comentarios y dificultades de implementación en máquinas multiprocesador reales. Ejemplo del protocolo Ethernet. “Binary exponential back-off” Programación Concurrente Clase 2

24 Algoritmo de desempate para la sincronización con Spin locks
Spin locks  no controlan el orden de los procesos demorados  es posible que alguno no entre nunca. Algoritmo tie-breaker: protocolo de SC que requiere solo scheduling débilmente fair y no usa instrucciones especiales, aunque es más complejo Usamos una variable adicional para romper empates. Ideas?? Programación Concurrente Clase 2

25 Algoritmo de desempate para la sincronización con Spin locks
Variable adicional para indicar cual proceso fue el último en comenzar a ejecutar el protocolo de entrada a la sección crítica last variable que indica cuál fue el último en comenzar a ejecutar su entry protocol se demora (quita prioridad) al último en comenzar su entry protocol. last es una variable compartida de acceso protegido. Programación Concurrente Clase 2

26 Algoritmo de desempate en sincronización por spin locks.
var in1 := false; in2 := false; last := 1 P1:: do true  in1 := true; last := # entry protocol do in2 and last = 1  skip od critical section in1 := false # exit protocol non-critical section od P2:: do true  in2 := true; last := # entry protocol do in1 and last = 2  skip od in2 := false # exit protocol Programación Concurrente Clase 2

27 Algoritmo de desempate para N procesos con Spin locks
Si hay n procesos, el entry protocol en cada uno es un loop que itera a través de n-1 etapas. En cada etapa, se usan instancias del tie-breaker para dos procesos para determinar cuáles avanzan a la siguiente etapa Si a lo sumo a un proceso a la vez se le permite ir por las n-1 etapas  a lo sumo uno a la vez puede estar en la SC. Programación Concurrente Clase 2

28 Algoritmo de desempate para N procesos usando spin locks.
var in[1..n] := ( [n] 0); last[1..n] := ( [n] 0) P[1..n]:: do true  fa j:=1 to n-1  # entry protocol #registra que el proceso i está en la etapa j y es el último in[i]:= j; last[j]:= i fa k:=1 to n st i<>k  #espera si el proceso k está en una etapa más alta #y espera si el proceso i fue el último en entrar en esta etapa do in[k] >= in[i] AND last[j]=i skip od af critical section in[i] := # exit protocol non-critical section od Programación Concurrente Clase 2

29 Algoritmo de ticket para desempate con N procesos.
tie-breaker n-procesos  complejo También costoso en tiempo ticket algorithm  se reparten tickets (números) y se espera turno Los clientes toman un número mayor que el tomado por cualquier otro que espera ser atendido; luego esperan hasta que todos los clientes con un número más chico sean atendidos. Programación Concurrente Clase 2

30 Algoritmo de ticket para desempate entre N procesos.
var number := 1, next := 1, turn[1:n] : int := ( [n] 0 ) { TICKET: ( P[i] está en su SC)  ( turn[i] = next)  ( i,j : 1  i, j  n, i  j: turn[i] = 0  turn[i]  turn[j] ) } P[i: 1..n] :: do true   turn[i] := number; number := number + 1   await turn[i] = next  critical section  next := next + 1  non-critical section od Problema potencial: los valores de number y next son ilimitados. Podemos resetear los contadores a un valor chico (por ej 1). Programación Concurrente Clase 2

31 Algoritmo de ticket para desempate entre N procesos.
El predicado TICKET resulta invariante global, dado que number es leído e incrementado en una acción atómica y next es incrementado en una acción atómica. Así hay a lo sumo un proceso en la sección crítica. La ausencia de deadlock y de demora innecesaria resultan del hecho que los valores de turn son únicos. Estos valores debieran (si el algoritmo se ejecuta por un largo período de tiempo) poder resetearse a partir de un nro. máximo N. Esto implica estar seguros que a lo sumo N clientes quieren acceder a la Sección Crítica. Programación Concurrente Clase 2

32 Algoritmo de ticket--->Solución de grano fino.
Solución de grano grueso---> instrucción atómica sobre number? Sea Fetch-and-Add una instrucción con el siguiente efecto: FA(var,incr):  temp := var; var := var + incr; return(temp)   var number := 1, next := 1, turn[1:n] : int := ( [n] 0 ) { TICKET: ( P[i] está en su SC)  ( turn[i] = next)  ( i,j : 1  i, j  n, i  j: turn[i] = 0  turn[i]  turn[j] ) } P[i: 1..n] :: do true  turn[i] := FA(number,1) do turn[i]  next  skip od critical section next := next + 1 non-critical section od Programación Concurrente Clase 2

33 El Algoritmo de Bakery--> Cuando NO tenemos una instrucción FA
Si no hay instrucción tipo FA, puede usarse una SC adicional: CSenter; turn[i] := number; number := number + 1; Csexit Esto es naturalmente menos eficiente y dificilmente fair. El algoritmo de Bakery NO requiere un contador global next que se “entregue”a cada proceso que quiere ingresar a la SC. Cada proceso que trata de ingresar recorre los números de los demás procesos y se autoasigna uno mayor luego espera que éste sea el menor número en espera. Esto requiere un invariante: { BAKERY: ( P[i] está ejecutando su SC)  ( turn[i]  0  ( ,j : 1  j  n, j  i: turn[j] = 0  turn[i] < turn[j] ) ) } Programación Concurrente Clase 2

34 Algoritmo de Bakery. Una solución de grano grueso.
var turn[1:n] : int := ( [n] 0 ) { BAKERY: ( P[i] está ejecutando su SC)  ( turn[i]  0  ( ,j : 1  j  n, j  i: turn[j] = 0  turn[i] < turn[j] ) ) } P[i: 1..n] :: do true   turn[i] := max(turn[1:n]) + 1  fa j := 1 to n st j  i   await turn[j] = 0 or turn[i] < turn[j]  af critical section  turn[i] := 0  non-critical section od Programación Concurrente Clase 2

35 Comentarios sobre la solución de grano grueso de Bakery.
La solución de grano grueso planteada es difícil de implementar en máquinas reales: por una parte nuevamente la asignación de turn[i] NO puede exceder un nro. máximo N. Por otra parte el AWAIT está referenciando una variable compartida dos veces, lo cual significa dos accesos atómicos a memoria. Analizaremos dos soluciones de grano fino con dos procesos que sincronizan por el algoritmo de Bakery, mostrando los problemas de la primer solución (que conducen a la segunda) Programación Concurrente Clase 2

36 Algoritmo de Bakery--->Primer Solución de grano fino.
var turn1:=0; turn2:= 0 P1:: do true  turn1:= turn2 +1 do turn2 <> 0 AND turn1 > turn2  skip od critical section turn1:= 0 non-critical section od P2:: do true  turn2:= turn1 +1 do turn1 <> 0 AND turn2 > turn1  skip od turn2:= 0 Problema: Ambos procesos pueden llegar a la SC al mismo tiempo. Programación Concurrente Clase 2

37 Algoritmo de Bakery--->Segunda Solución de grano fino.
var turn1:=0; turn2:= 0 P1:: do true  turn1:= turn2 +1 do turn2 <> 0 AND turn1 > turn2  skip od critical section turn1:= 0 non-critical section od P2:: do true  turn2:= turn1 +1 do turn1 <> 0 AND turn2 >= turn1  skip od turn2:= 0 Le estamos dando PRECEDENCIA(prioridad) a P1 sobre P2 Programación Concurrente Clase 2

38 Tareas para la próxima clase
Estudiar el problema de las 8 reinas en un tablero de ajedrez. Analizar un algoritmo secuencial posible para establecer todas las soluciones. Demostrar que existen 92 soluciones. Analizar una posible solución recursiva. Estudiar la paralelización de la solución anterior. Expresar conceptualmente la paralelización. Cuántos procesos concurrentes definiría Ud. ?? Leer la teoría de semáforos del texto de Andrews u otro Programación Concurrente Clase 2

39 Ejercicio para la promoción
P= 4 n=16 Cuántas asignaciones, sumas y productos hace c/Procesador? Si P1=P2=P3 y los tiempos de asignación con 1, de suma 2 y de producto 3, si P4 es 4 veces más lento, Cuánto tarda el proceso total? Qué haría Ud. en bien del speed-up?? process worker[w = 1 to P] { # strips en paralelo int first = (w-1) * n/P; # Primer fila del strip int last = first + n/P - 1; # Ultima fila del strip for [i = first to last] { for [j = 0 to n-1] { c[i,j] = 0.0; for [k = 0 to n-1] c[i,j] = c[i,j] + a[i,k]*b[k,j]; } Programación Concurrente Clase 1