Transcript Conceptos de la clase anterior

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 (finegrained) 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
19-4-2004
1
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.
19-4-2004
Programación Concurrente 2004 - Clase 2
2
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”...
19-4-2004
Programación Concurrente 2004 - Clase 2
3
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
19-4-2004
Programación Concurrente 2004 - Clase 2
4
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)
19-4-2004
Programación Concurrente 2004 - Clase 2
5
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.
19-4-2004
Programación Concurrente 2004 - Clase 2
6
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
19-4-2004
Programación Concurrente 2004 - Clase 2
7
Sincronización por variables
compartidas
busy waiting  un proceso chequea repetidamente
una condición hasta que es verdadera
Ventaja: implementación
cualquier procesador.
con
instrucciones
de
Ineficiente en multiprogramación
Aceptable si cada proceso se ejecuta en su procesador
19-4-2004
Programación Concurrente 2004 - Clase 2
8
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??
19-4-2004
Programación Concurrente 2004 - Clase 2
9
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.
19-4-2004
Programación Concurrente 2004 - Clase 2
10
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
19-4-2004
Programación Concurrente 2004 - Clase 2
11
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
19-4-2004
Programación Concurrente 2004 - Clase 2
12
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
19-4-2004
Programación Concurrente 2004 - Clase 2
13
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.
19-4-2004
Programación Concurrente 2004 - Clase 2
14
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
19-4-2004
Programación Concurrente 2004 - Clase 2
15
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.
19-4-2004
Programación Concurrente 2004 - Clase 2
16
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 
critical section
lock:= false
non-critical section
od
P2 :: do true   await not lock  lock:= true 
critical section
lock := false
non-critical section
od
# entry protocol
# exit protocol
# entry protocol
# exit protocol
Notar que P1 y P2 quedan idénticos.
19-4-2004
Programación Concurrente 2004 - Clase 2
17
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 2004 - Clase 2
19-4-2004
18
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
19-4-2004
19
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.)
19-4-2004
Programación Concurrente 2004 - Clase 2
20
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
TS(lock,cc)
19-4-2004
# spin mientras lock está seteado
Programación Concurrente 2004 - Clase 2
21
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
S
SC Exit
#protocolo de entrada a la SC
#protocolo de salida de la SC
Para implementar una acción atómica condicional await B  S:
SC Enter
do not B  SC Exit;
S
SC Exit
19-4-2004
SC Enter od
Programación Concurrente 2004 - Clase 2
22
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”
19-4-2004
Programación Concurrente 2004 - Clase 2
23
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??
19-4-2004
Programación Concurrente 2004 - Clase 2
24
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.
19-4-2004
Programación Concurrente 2004 - Clase 2
25
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
19-4-2004
Programación Concurrente 2004 - Clase 2
26
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.
19-4-2004
Programación Concurrente 2004 - Clase 2
27
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
af
critical section
in[i] := 0
# exit protocol
non-critical section
od
19-4-2004
28 2
Programación Concurrente 2004 - Clase
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.
19-4-2004
Programación Concurrente 2004 - Clase 2
29
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).
19-4-2004
Programación Concurrente 2004 - Clase 2
30
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.
19-4-2004
Programación Concurrente 2004 - Clase 2
31
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
19-4-2004
Programación Concurrente 2004 - Clase 2
32
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 2004 - Clase 2
19-4-2004
33
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
19-4-2004
34
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)
19-4-2004
Programación Concurrente 2004 - Clase 2
35
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.
19-4-2004
Programación Concurrente 2004 - Clase 2
36
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
19-4-2004
Programación Concurrente 2004 - Clase 2
37
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 2004 - Clase 2
19-4-2004
38
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
19-4-2004
39 1
}