Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Sincronizacion
Sincronizacion
Sincronización,
Concurrencia y
Transacciones
Sincronización en Sistemas Distribuidos
Tiempo y Estados
•Relojes Distribuidos
•Relojes Lógicos
•Estados Globales
Sincronización de Relojes Físicos
tiempo
T1
Organización:
– Jerarquía de servidores en diferentes estratos.
– Los fallos se solventan por medio de ajustes en la jerarquía.
No sincronizado Sincronizado
+1
+1
Para evitar los casos en los que LCa < LCb no implica a b.
Cada reloj es un array V de N elementos siendo N el número de
procesadores (nodos) del sistema.
– Inicialmente Vi[j]=0 para todo i,j
– Cuando el proceso i genera un evento Vi[i]=Vi[i]+1
– Cuando en el nodo i se recibe un mensaje del nodo j con un vector
de tiempo t entonces:
• para todo k: Vi[k]=max(Vi[k],t[k]) (operación de mezcla) y
• Vi[i]=Vi[i] + 1
AF (100)<(252)
(000)
B||J (300)<(025) AND (300)>(025)
Sistemas Operativos Distribuidos Fernando Pérez Costoya
13 José María Peña Sánchez
Uso de los Relojes Lógicos
m1 m2 ..... mk
Sj Cij Si
Lij={m1,..,mk }
Sistemas Operativos Distribuidos Fernando Pérez Costoya
16 José María Peña Sánchez
Snapshots
m1 m1
m2 m4 no se m2
ha enviado
m3 m3
m4 ya ha
m4 m4
llegado
m5 m5
Propiedad de estabilidad:
S=INICIALIZADO
Propiedad de seguridad:
S=NO_USABLE TU
Propiedad de vivacidad:
U>0 U<T
Sistemas Operativos Distribuidos Fernando Pérez Costoya
20 José María Peña Sánchez
Estados Globales: Propiedades
Se interpreta como:
– “El evento e puede producirse cuando el procesador p está en el
estado s y le llega un mensaje m por el canal c. Dicho evento causa
que p pase del estado s a s’.”
Instante 13:
Estado:
s=( p1{} , p2{} , pc{memory={2},jobs={7}} , pd={reading=no} )
Canales:
ccd={3}
Sistemas Operativos Distribuidos Fernando Pérez Costoya
27 José María Peña Sánchez
Ejemplo
B Cc1
1 Ccd {3}
C1c
cache disk
Cdc
C2c
2
Cc2
Instante 9:
Estado:
s=( p1{} , p2{} , pc{memory= ,jobs={7}} , pd={reading=2} )
Canales:
ccd={3} Incumple la propiedad [s2] de
seguridad
Sistemas Operativos Distribuidos Fernando Pérez Costoya
28 José María Peña Sánchez
Sistemas Operativos Distribuidos
Exclusión Mutua
•Algoritmos de
Exclusión Mutua
Exclusión Mutua
Problemática:
– No existen variables compartidas
– Riesgo de interbloqueos
– Riesgo de inanición
Sistemas Operativos Distribuidos Fernando Pérez Costoya
30 José María Peña Sánchez
Exclusión Mutua
Propiedades:
– Seguridad: Como máximo un proceso puede estar ejecutado en la
sección crítica a la vez.
– Vivacidad: Eventualmente se producen entradas y salidas en la
sección crítica.
– Ordenación: Los procesadores acceden a la región crítica en base a
unos criterios de ordenación (causalidad temporal/Lamport).
0 1 2 0 1 2 0 1 2
enter exit
enter OK
OK No hay respuespuesta
(bloquea al cliente)
C C C
Rendimiento:
– Ancho de banda:
• El acceso al recurso implica dos mensajes (aunque el recurso esté
libre).
– Retardo del cliente:
• enter(): El retardo de transmisión de los dos mensajes.
• exit(): Con comunicación asíncrona no implica retraso en cliente.
– Throughput del sistema:
• La finalización de un acceso a la región critica implica un mensaje de
salida y un OK al siguiente proceso en espera.
– Tolerancia a fallos:
• La caída del elemento de control es crítica (alg. de elección).
• La caída de los clientes o la perdida de mensajes se puede solucionar
por medio de temporizadores.
Sistemas Operativos Distribuidos Fernando Pérez Costoya
34 José María Peña Sánchez
Exclusión Mutua Distribuida
token
Rendimiento:
– Ancho de banda:
• El algoritmo consume ancho banda de forma continua.
– Retardo del cliente:
• La entrada en la sección critica requiere de 0 a N mensajes.
• La salida sólo implica un mensaje.
– Throughput del sistema:
• La entrada del siguiente proceso tras la salida del que ocupa la región
critica implica de 1 a N mensajes.
– Tolerancia a fallos:
• Perdida del token: Detección y regeneración
• Caída de un elemento del anillo: Reconfiguración del anillo.
1
2
OK
23
WANTED 3
21
Rendimiento:
– Ancho de banda:
• El protocolo consume 2(N-1) mensajes. N-1 para la petición y N-1
respuestas. Si existen comunicación multicast sólo N mensajes.
– Retardo del cliente:
• La entrada en la sección critica requiere de N-1 mensajes.
• La salida no implica ningún mensaje.
– Throughput del sistema:
• Si dos procesos compiten por el acceso a la sección critica ambos
habrán recibido N-2 respuestas. El de menor reloj tendrá la respuesta
del otro. Al salir éste el siguiente se indicará con sólo 1 mensaje.
– Tolerancia a fallos:
• Retardo de respuesta elevado o perdida de mensajes: Se reduce por
medio de mensajes NO-OK (asentimientos negativos).
Sistemas Operativos Distribuidos Fernando Pérez Costoya
39 José María Peña Sánchez
Algoritmos de Votación
1 2 3 4 5 6 7
Componente
8 9 10 11 12 13 14 Decisivo
15 16 17 18 19 20 21
22 23 24 25 26 27 28
Distrito de Sj
29 30 31 32 33 34 35
36 37 38 39 40 41 42
43 44 45 46 47 48 49
Distrito de Si
Sistemas Operativos Distribuidos Fernando Pérez Costoya
41 José María Peña Sánchez
Otras Variantes
Problemas de
Consenso
•Algoritmos de Elección
•Consenso & Acuerdo
Algoritmos de Elección
Objetivo
– Elige al procesador “vivo” con un ID mayor
1 1 1
2 5 2 5 2 5
n
Elección OK
4 4 4
ció
6 6 6
c
Ele
El
ec
ci
ón
0 3 0 3 0 3
7 7 7
1 1
2 5 2 5
OK Coordinador
4 6 4 6
Coordinador
0 3 0 3
7 7
Condiciones:
– Terminación: Cada proceso correcto fija un valor.
– Acuerdo: El valor decidido es igual para todos los procesos correctos.
– Integridad: Si todos los procesos correctos eligen el mismo valor
entonces dicho valor será el válido.
V=3 p2 p2
p1 p1 D=3
D=3
V=3 Algoritmo Algoritmo
de V=2 de
Consenso Consenso
p4 p4
p3 p3
V=5
Proceso D=3
Caído
Sistemas Operativos Distribuidos Fernando Pérez Costoya
51 José María Peña Sánchez
Consistencia Interactiva
Condiciones:
– Terminación: Cada proceso correcto fija un vector valores.
– Acuerdo: El vector decidido es igual para todos los procesos correctos
– Integridad: La posición i-esima del vector se corresponde con el valor
propuesto por el proceso pi
V=3 p2 p2
p1 p1 D=(3,3,5,2)
D =(3,3,5,2)
V=3 Algoritmo Algoritmo
de V=2 de
Consistencia Consistencia
p4 p4
p3 p3
V=5
Proceso D =(3,3,5,2)
Caído
Sistemas Operativos Distribuidos Fernando Pérez Costoya
52 José María Peña Sánchez
Generales Bizantinos
TRAIDOR
retirada retirada
L L L L
ataque ataque
ataque=1 ataque=1
retirada=1 G3T retirada=1
TRAIDOR
ataque C retirada ataque C ataque
ataque ataque TRAIDOR ataque ataque
retirada ataque
L L L L L L
ataque ataque ataque ataque
ataque ataque=2 retirada ataque=2
retirada=1 retirada=1
retirada ataque
Sistemas Operativos Distribuidos Fernando Pérez Costoya
53 José María Peña Sánchez
Sistemas Operativos Distribuidos
Transacciones
Distribuidas
•Operaciones Atómicas
•Two-Phase Commit
Transacciones
Actualización perdida:
bal=B.getBalance() bal=B.getBalance()
B.setBalance(bal*1.1) B.setBalance(bal*1.1)
A.withdraw(bal*0.1) C.withdraw(bal*0.1)
bal=B.getBalance() $200
bal=B.getBalance() $200
B.setBalance(bal*1.1) $220
B.setBalance(bal*1.1) $220
A.withdraw(bal*0.1) $80
C.withdraw(bal*0.1) $280
Recuperaciones inconsistentes:
A.withdraw(100) <suma de saldos>
B.deposit(100)
A.withdraw(100) $0
tot=A.getBalance() $0
tot+=B.getBalance() $300
tot+=C.getBalance() $500
B.deposit(100) $400
Actualización perdida:
bal=B.getBalance() bal=B.getBalance()
B.setBalance(bal*1.1) B.setBalance(bal*1.1)
bal=B.getBalance()$200 Lb
bal=B.getBalance()$200 Lb
lock
• •
lock
• • wait
B.setBalance(bal*1.1)$220 Lb • •
unlock bal=B.getBalance()$200 Lb
B.setBalance(bal*1.1)$220
Sistemas Operativos Distribuidos Fernando Pérez Costoya
62 José María Peña Sánchez
Interbloqueos
A
T U
B
Validación:
– Validación hacia atrás: Se anula una transacción si otra transacción
activa escribe un valor que ésta lee.
– Validación hacia delante: Todos los procesos de escritura realizados
anulan a las transacciones que los leían.
Problemática:
– Si la fase de validación falla la transacción se aborta y se reinicia.
Puede causar inanición.
Sistemas Operativos Distribuidos Fernando Pérez Costoya
65 José María Peña Sánchez
Transacciones Distribuidas
doCommit
haveCommitted
Subordinados: P0 P1 P2
Recibir canCommit?()
canCommit?
Decidir respuesta y grabar en mem.estable
Mandar respuesta: getDecision()
Recibir resolución
Escribir resolución en mem. estable getDecision(ok) getDecision(ok)
Llevar a cabo resolución:
doCommit()=> hacer cambios permanentes
doAbort() => deshacer cambios doCommit
haveCommitted
Fases:
– El coordinador transmite canCommit?() a todos los servidores.
– Los servidores responden con getDecision() al coordinador.
– El coordinador recolecta las respuestas y manda:
• preCommit() : Si todos aceptan.
• doAbort() : Si todos aceptan.
– Los servidores con un asentimiento.
– Cuando todos los asentimientos han sido recibidos entonces
transmite doCommit()