La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

19-4-20041 Conceptos de la clase anterior Sincronizar => Combinar acciones atómicas de grano fino (fine- grained) en acciones (compuestas) de grano grueso.

Presentaciones similares


Presentación del tema: "19-4-20041 Conceptos de la clase anterior Sincronizar => Combinar acciones atómicas de grano fino (fine- grained) en acciones (compuestas) de grano grueso."— Transcripción de la presentación:

1 19-4-20041 Conceptos de la clase anterior 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 2004 - Clase 2 Especificar la concurrencia es esencialmente especificar los procesos concurrentes, su comunicación y sincronización.

2 19-4-20042 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 2004 - Clase 2

3 19-4-20043 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 2004 - Clase 2

4 19-4-20044 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 2004 - Clase 2

5 19-4-20045 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 2004 - Clase 2

6 19-4-20046 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 memoriapara favorecer a los procesos retrasados y lograr fairness: Prioridades dinámicas. Programación Concurrente 2004 - Clase 2

7 19-4-20047 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 2004 - Clase 2

8 19-4-20048 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 2004 - Clase 2

9 19-4-20049 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 2004 - Clase 2

10 19-4-200410 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 2004 - Clase 2

11 19-4-200411 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 critical section in2 := false # exit protocol non-critical section od El protocolo utilizado NO asegura el invariante MUTEX Programación Concurrente 2004 - Clase 2

12 19-4-200412 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 2004 - Clase 2

13 19-4-200413 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 2004 - Clase 2

14 19-4-200414 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 2004 - Clase 2

15 19-4-200415 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 2004 - Clase 2

16 19-4-200416 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 2004 - Clase 2

17 19-4-200417 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 2004 - Clase 2

18 19-4-200418 Sincronización por Sección Crítica. Una solución de grano fino. En TS se tienen dos argumentos booleanos: una variable compartida lock y un código de condición local, cc Programación Concurrente 2004 - Clase 2 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.

19 19-4-200419 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 2004 - Clase 2

20 19-4-200420 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 2004 - Clase 2

21 19-4-200421 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 2004 - Clase 2

22 19-4-200422 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 2004 - Clase 2

23 19-4-200423 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 2004 - Clase 2

24 19-4-200424 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 2004 - Clase 2

25 19-4-200425 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 2004 - Clase 2

26 19-4-200426 Algoritmo de desempate en sincronización por spin locks. var in1 := false; in2 := false; last := 1 P1:: do true in1 := true; last := 1 # 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 := 2 # entry protocol do in1 and last = 2 skip od critical section in2 := false # exit protocol non-critical section od Programación Concurrente 2004 - Clase 2

27 19-4-200427 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 2004 - Clase 2

28 19-4-200428 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] := 0 # exit protocol non-critical section od Programación Concurrente 2004 - Clase 2

29 19-4-200429 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 2004 - Clase 2

30 19-4-200430 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 2004 - Clase 2

31 19-4-200431 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 2004 - Clase 2

32 19-4-200432 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 2004 - Clase 2

33 19-4-200433 El Algoritmo de Bakery--> Cuando NO tenemos una instrucción FA El algoritmo de Bakery NO requiere un contador global next que se entreguea 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 2004 - Clase 2 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.

34 19-4-200434 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 2004 - Clase 2

35 19-4-200435 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 2004 - Clase 2

36 19-4-200436 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 critical section turn2:= 0 non-critical section od Problema: Ambos procesos pueden llegar a la SC al mismo tiempo. Programación Concurrente 2004 - Clase 2

37 19-4-200437 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 critical section turn2:= 0 non-critical section od Le estamos dando PRECEDENCIA(prioridad) a P1 sobre P2 Programación Concurrente 2004 - Clase 2

38 19-4-200438 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. Leer la teoría de semáforos del texto de Andrews u otro Programación Concurrente 2004 - Clase 2 Estudiar la paralelización de la solución anterior. Expresar conceptualmente la paralelización. Cuántos procesos concurrentes definiría Ud. ??

39 19-4-200439 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 2004 - Clase 1


Descargar ppt "19-4-20041 Conceptos de la clase anterior Sincronizar => Combinar acciones atómicas de grano fino (fine- grained) en acciones (compuestas) de grano grueso."

Presentaciones similares


Anuncios Google