Conceptos de la clase anterior

1
Conceptos de la clase anterior

Especificar la concurrencia es esencialmente
especificar los procesos concurrentes, su
comunicación y sincronización.
Sincronizar gt Combinar acciones atómicas de
grano fino (fine-grained) en acciones
(compuestas) de grano grueso (coarse grained) que
den la exclusión mutua.
Sincronizargt Demorar un proceso hasta que el
estado de programa satisfaga algún predicado (por
condición).
Programación Concurrente 2004 - 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 2004 - 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 2004 - 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 2004 - 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 2004 - 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 memoriapara favorecer a
los procesos retrasados y lograr fairness ?
Prioridades dinámicas.
Programación Concurrente 2004 - Clase 2
7
Especificación de la sincronización.

Sincronización por condición ? ? await B
? Ejemplo ? await count gt 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
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
Sincronización por variables compartidas? Sección
Crítica

Pi1..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
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
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
Sincronización por Sección Crítica

MUTEX invariante---gtfortalecer 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
Sincronización por Sección Crítica

MUTEX invariante---gtfortalecer 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
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
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
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
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
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 TestSet (TS), FetchAdd o
CompareSwap.
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
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 TestSet las 4 propiedades se pueden
cumplir, y cada proceso (ver la solución que
sigue) queda dando vueltas hasta que lock lo
habilita?gt Spin Locks
Programación Concurrente 2004 - Clase 2
20
Sincronización por Sección Crítica. Una solución
de grano fino con TS.

var lock false
P1 var ccbool do true ? TS (lock, cc)
entry protocol
do cc--gt 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
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 TestSet do lock ? skip od
spin mientras lock está seteado
TS(lock,cc)
Programación Concurrente 2004 - 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 2004 - 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 2004 - 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 2004 - 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 2004 - 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 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
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
Algoritmo de desempate para N procesos usando
spin locks.

var in1..n ( n 0) last1..n ( n
0) P1..n do true ? fa j1
to n-1 ? entry
protocol registra que el proceso i está en la
etapa j y es el último
ini j lastj i
fa k1 to n st iltgtk ? 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 ink gt ini
AND lastji ?skip od
af af
critical section ini 0
exit
protocol non-critical section
od
Programación Concurrente 2004 - 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 2004 - Clase 2
30
Algoritmo de ticket para desempate entre N
procesos.

var number 1, next 1, turn1n int (
n 0 ) TICKET ( Pi está en su SC) ? (
turni next) ? ( ?i,j 1 ?
i, j ? n, i ? j turni 0 ? turni ? turnj
) Pi 1..n do true ?
? turni number number number 1 ?
? await turni 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
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
Algoritmo de ticket---gtSolución de grano fino.

Solución de grano grueso---gt 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, turn1n
int ( n 0 ) TICKET ( Pi está en su SC)
? ( turni next) ? ( ?i,j 1
? i, j ? n, i ? j turni 0 ? turni ?
turnj ) Pi 1..n do true ?
turni FA(number,1)
do turni ? next ? skip od
critical section next
next 1 non-critical
section od
Programación Concurrente 2004 - Clase 2
33
El Algoritmo de Bakery--gt Cuando NO tenemos una
instrucción FA

Si no hay instrucción tipo FA, puede usarse una
SC adicional CSenter turni 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 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 ( Pi
está ejecutando su SC) ? ( turni ? 0 ?
( ?,j 1 ? j ? n, j ? i turnj 0 ?
turni lt turnj ) )
Programación Concurrente 2004 - Clase 2
34
Algoritmo de Bakery. Una solución de grano grueso.

var turn1n int ( n 0 ) BAKERY (
Pi está ejecutando su SC) ? ( turni ? 0 ?
( ?,j 1 ? j ? n, j ? i turnj
0 ? turni lt turnj ) ) Pi 1..n do
true ? ? turni
max(turn1n) 1 ? fa j
1 to n st j ? i ?
? await turnj 0 or turni lt turnj ?
af
critical section ? turni
0 ? non-critical
section od
Programación Concurrente 2004 - 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 turni 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
Algoritmo de Bakery---gtPrimer Solución de grano
fino.

var turn10 turn2 0 P1 do true ? turn1
turn2 1 do turn2 ltgt 0
AND turn1 gt turn2 ? skip od
critical section
turn1 0 non-critical
section od P2 do true ? turn2 turn1 1
do turn1 ltgt 0 AND turn2
gt 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
Algoritmo de Bakery---gtSegunda Solución de grano
fino.

var turn10 turn2 0 P1 do true ? turn1
turn2 1 do turn2 ltgt 0
AND turn1 gt turn2 ? skip od
critical section
turn1 0 non-critical
section od P2 do true ? turn2 turn1 1
do turn1 ltgt 0 AND turn2
gt 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
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
39
Ejercicio para la promoción

P 4 n16 Cuántas asignaciones, sumas y
productos hace c/Procesador? Si P1P2P3 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 workerw 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 ci,j
0.0 for k 0 to n-1
ci,j ci,j ai,kbk,j

Programación Concurrente 2004 - Clase 1