Você está na página 1de 71

Sistemas Operativos Distribuidos

Sincronizacin,
Concurrencia y
Transacciones
Sincronizacin en Sistemas Distribuidos

Ms compleja que en los centralizados

Propiedades de algoritmos distribuidos:


La informacin relevante se distribuye entre varias mquinas.
Se toman decisiones slo en base a la informacin local.
Debe evitarse un punto nico de fallo.
No existe un reloj comn.
Problemas a considerar:
Tiempo y estados globales.
Exclusin mutua.
Algoritmos de eleccin.
Operaciones atmicas distribuidas: Transacciones

Sistemas Operativos Distribuidos Fernando Prez Costoya


2 Jos Mara Pea Snchez
Sistemas Operativos Distribuidos

Tiempo y Estados

Relojes Distribuidos
Relojes Lgicos
Estados Globales
Sincronizacin de Relojes Fsicos

Relojes hardware de un sistema distribuido no estn


sincronizados.
Necesidad de una sincronizacin para:
En aplicaciones de tiempo real.
Ordenacin natural de eventos distribuidos (fechas de ficheros).
Concepto de sincronizacin:
Mantener relojes sincronizados entre s.
Mantener relojes sincronizados con la realidad.
UTC: Universal Coordinated Time
Transmisin de seal desde centros terrestres o satlites.
Una o ms mquinas del sistema distribuido son receptoras de seal
UTC.
Sistemas Operativos Distribuidos Fernando Prez Costoya
4 Jos Mara Pea Snchez
Algoritmo de Cristian
Servidor
Cliente de tiempos
T0 petici
tiempo n

Tiempo del manejador


I de interrupciones

tiempo
T1

Adecuado para sincronizacin con UTC.


Tiempo de transmisin del mensaje: (T1-T0)/2
Tiempo en propagar el mensaje: (T1-T0-I)/2
Valor que devuelve el servidor se incrementa en (T1-T0-I)/2
Para mejorar la precisin se pueden hacer varias mediciones y
descartar cualquiera en la que T1-T0 exceda de un lmite
Sistemas Operativos Distribuidos Fernando Prez Costoya
5 Jos Mara Pea Snchez
Algoritmo de Berkeley

El servidor de tiempo realiza un muestreo peridico de todas


las mquinas para pedirles el tiempo.
Calcula el tiempo promedio y le indica a todas las mquinas
que avancen su reloj a la nueva hora o que disminuyan la
velocidad.
Si cae servidor: seleccin de uno nuevo (alg. de eleccin)
3:00 3:00 3:00 0 3:00 +5

3:00 +25 -20

3:00 -10 +15

3:25 2:50 3:25 2:50 3:25 2:50

Sistemas Operativos Distribuidos Fernando Prez Costoya


6 Jos Mara Pea Snchez
Protocolo de Tiempo de Red

NTP (Network Time Protocol).


Aplicable a redes amplias (Internet).
La latencia/retardo de los mensajes es significativa y variable.
Objetivos:
Permitir sincronizar clientes con UTC sobre Internet.
Proporcionar un servicio fiable ante fallos de conexin.
Permitir resincronizaciones frecuentes.
Permitir proteccin ante interferencias del servicio de tiempo.

Organizacin:
Jerarqua de servidores en diferentes estratos.
Los fallos se solventan por medio de ajustes en la jerarqua.

Sistemas Operativos Distribuidos Fernando Prez Costoya


7 Jos Mara Pea Snchez
Protocolo de Tiempo de Red

La sincronizacin entre cada par de elementos de la jerarqua:


Modo multicast: Para redes LAN. Se transmite por la red a todos los
elementos de forma peridica. Baja precisin.
Modo de llamada a procedimiento: Similar al algoritmo de Cristian.
Se promedia el retardo de transmisin. Mejor precisin.
Modo simtrico: Los dos elementos intercambian mensajes de
sincronizacin que ajustan los relojes. Mayor precisin.

Los mensajes intercambiados entre dos servidores son


datagramas UDP.

Sistemas Operativos Distribuidos Fernando Prez Costoya


8 Jos Mara Pea Snchez
Causalidad Potencial

En ausencia de un reloj global la relacin causa-efecto (tal como


precede a) es una posibilidad de ordenar eventos.

Relacin de causalidad potencial (Lamport)


eij = evento j en el proceso i
Si j < k entonces eij eik
Si ei=send(m) y ej=receive(m), entonces ei ej
La relacin es transitiva.

Dos eventos son concurrentes (a || b) si no se puede deducir


entre ellos una relacin de causalidad potencial.

Sistemas Operativos Distribuidos Fernando Prez Costoya


9 Jos Mara Pea Snchez
Relojes Lgicos (Algoritmo de Lamport)

tiles para ordenar eventos en ausencia de un reloj comn.


Cada proceso P mantiene una variable entera LCP (reloj lgico)
Cuando un proceso P genera un evento, LCP=LCP+1
Cuando un proceso enva un mensaje incluye el valor de su reloj
Cuando un proceso Q recibe un mensaje m con un valor t:
LCQ=max(LCQ,t)+1
El algoritmo asegura:
Que si a b entonces LCa < LCb
Pero LCa < LCb no implica a b (pueden ser concurrentes)
Relojes lgicos slo representan una relacin de orden parcial.
Orden total entre eventos si se aade el nmero del
procesador.
Sistemas Operativos Distribuidos Fernando Prez Costoya
10 Jos Mara Pea Snchez
Algoritmo de Lamport

No sincronizado Sincronizado

+1
+1

Sistemas Operativos Distribuidos Fernando Prez Costoya


11 Jos Mara Pea Snchez
Relojes de Vectores (Mattern y Fidge)

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 nmero 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]) (operacin de mezcla) y
Vi[i]=Vi[i] + 1

Por medio de este mecanismo siempre es posible evaluar si dos


marcas de tiempo tienen o no relacin de precedencia.

Sistemas Operativos Distribuidos Fernando Prez Costoya


12 Jos Mara Pea Snchez
Algoritmo de Mattern y Fidge

A (100) (200) B (300) C (400) (562) D (662)

E (010) (020) (230) (242) F (252) (262) (276) G (286)

H (001) (002) I (003) (024) J(025) (026) K (027)

AF (100)<(252)
(000)
B||J (300)<(025) AND (300)>(025)
Sistemas Operativos Distribuidos Fernando Prez Costoya
13 Jos Mara Pea Snchez
Uso de los Relojes Lgicos

La utilizacin de relojes lgicos (Lamport, Vectoriales o


Matriciales) se aplica a:
Mensajes peridicos de sincronizacin.
Campo adicional en los mensajes intercambiados (piggybacked).

Por medio de relojes lgicos se pueden resolver:


Ordenacin de eventos (factores de prioridad o equitatividad).
Deteccin de violaciones de causalidad.
Multicast causal (ordenacin de mensajes).

Sistemas Operativos Distribuidos Fernando Prez Costoya


14 Jos Mara Pea Snchez
Estados Globales

En un sistema distribuido existen ciertas situaciones que no es


posible determinar de forma exacta por falta de un estado
global:
Recoleccin de basura: Cuando un objeto deja de ser referenciado
por ningn elemento del sistema.

Deteccin de interbloqueos: Condiciones de espera cclica en grafos


de espera (wait-for graphs).

Deteccin de estados de terminacin: El estado de actividad o


espera no es suficiente para determinar la finalizacin de un proceso.

Sistemas Operativos Distribuidos Fernando Prez Costoya


15 Jos Mara Pea Snchez
Estados Globales

El estado global de un sistema distribuido se denota por G=(S,L),


donde:
S={s1, s2, s3, s4,...,sM} : Estado interno de cada uno de los M
procesadores.
L={Li,j| i,j 1..M} : Li,j Estado de los canales unidireccionales Ci,j entre
los procesadores. El estado del canal son los mensajes en l encolados

m1 m2 ..... mk

Sj Cij Si
Lij={m1,..,mk }
Sistemas Operativos Distribuidos Fernando Prez Costoya
16 Jos Mara Pea Snchez
Snapshots

El anlisis de los estados globales de un sistema se realiza por


medio de snapshots: Agregacin del estado local de cada
componente as como de los mensajes actualmente en
transmisin.

Debido a la imposibilidad de determinar el estado global de todo


el sistema en un mismo instante se define una propiedad de
consistencia en la evaluacin de dicho estado.

Sistemas Operativos Distribuidos Fernando Prez Costoya


17 Jos Mara Pea Snchez
Cortes Consistentes

Corte no consistente Corte consistente


p1 p2 p3 p1 p2 p3

m1 m1
m2 m4 no se m2
ha enviado

m3 m3
m4 ya ha
m4 m4
llegado
m5 m5

Sistemas Operativos Distribuidos Fernando Prez Costoya


18 Jos Mara Pea Snchez
Estados Globales: Propiedades

El uso de estados globales es aplicable para la definicin de una


serie de propiedades:
Propiedades de estabilidad: Una vez que se cumple dicha
propiedad, para todo estado posterior dicha propiedad sigue siendo
verdadera.
Propiedades de seguridad: Todos los estados alcanzables por el
sistema deben cumplir dicha propiedad.
Propiedades de vivacidad: Debe ser posible cumplir dicha
propiedad alguna vez durante la ejecucin del sistema.

La verificacin de un sistema/algoritmo distribuido se basa en la


definicin y cumplimiento de dichas propiedades.

Sistemas Operativos Distribuidos Fernando Prez Costoya


19 Jos Mara Pea Snchez
Estados Globales: Propiedades

Ejemplo: Un buffer intermedio de almacenamiento.


Variables de estado:
S:{NO_USABLE,INICIALIZADO} // Estado del buffer
T:entero // Tamao del buffer
U:entero // Ocupacin del buffer

Propiedad de estabilidad:
S=INICIALIZADO
Propiedad de seguridad:
S=NO_USABLE TU
Propiedad de vivacidad:
U>0 U<T
Sistemas Operativos Distribuidos Fernando Prez Costoya
20 Jos Mara Pea Snchez
Estados Globales: Propiedades

La evolucin de las propiedades de un sistema se estudian por


medio las alteraciones producidas por la ejecucin de
operaciones sobre este elemento.

Estas operaciones se solicitan por medio de eventos:


Eventos internos: Operaciones internas de un procesador del
sistema.
Eventos externos: Operaciones solicitadas por un procesador del
sistema a otro. Lleva asociado la llegada de un mensaje.

Sistemas Operativos Distribuidos Fernando Prez Costoya


21 Jos Mara Pea Snchez
Anlisis de un Sistema Distribuido

Estado del sistema: G=(S,L). S estado de los procesadores y L


estado de los canales entre ellos.
Evento: e=(p,s,s,m,c) donde:
p P : Procesador/componente del sistema.
s,s S : Estados posibles de un componente del sistema.
m M : Mensaje. Puede ser NULL si es un evento interno.
c C : Canal de mensajes entre los componentes. Puede ser NULL.

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.

Sistemas Operativos Distribuidos Fernando Prez Costoya


22 Jos Mara Pea Snchez
Anlisis de un Sistema Distribuido

G estado actual del sistema, siendo sp es el estado actual del


procesador p.
El evento e=(p,s,s,c,m) puede producirse en G sii:
sp=s
c no es NULL y es un canal entrante a p entonces head(Lc)=m
Si el evento e se produce el sistema transita del estado G a G
(denotado G e G), siendo Lc=(m1,...,mk):
sp =s, el resto de procesadores conservaran su estado.
Si c es un canal saliente de p entonces Lc=(m1,...,mk,m).
Si c es un canal entrante a p entonces Lc=(m2,...,mk).
El resto de canales permanecen igual.

Sistemas Operativos Distribuidos Fernando Prez Costoya


23 Jos Mara Pea Snchez
Ejemplo

Estados de cada procesador:


p1 y p2: Ninguno
pc (cache): memory{1,2,3,...,10}, jobs=queue({1,2,3,...,10})
pd (disk): reading=no {1,2,3,...,10}
Ejemplo:
s=( p1{} , p2{} , pc{memory={1,4,6},jobs={2}} , pd={reading=3} )
Cc1
1 Ccd
C1c
cache disk
Cdc
C2c
2
Cc2
Sistemas Operativos Distribuidos Fernando Prez Costoya
24 Jos Mara Pea Snchez
Ejemplo
Mensajes: M ={1,2,3,...,10}
Eventos:
eenvia_peticin(1,n)=(1,{},{},{n},c1c)
eenvia_peticin(2,n)=(2,{},{},{n},c2c)
erecibe_peticin(i,n)=(cache,s {jobs=q},s {jobs=append(q,n)},{n},cic)
eenvia_tarea(n)=(cache,s {jobs=q},s {jobs=head(q,n)},{n},ccd)
erecibe_tarea(n)=(disk,{reading=no},{reading=n},{n},ccd)
eenvia_dato(n)=(disk,{reading=n},{reading=no},{n},cdc)
erecibe_dato(n)=(cache, s {memory=M}, s {memory=M {n}},{n},cdc)
eenvia_respuesta(i,n)=(cache, s, s,{n},cci)
erecibe_respuesta(1,n)=(1, {}, {},{n},cc1)
erecibe_respuesta(2,n)=(2, {}, {},{n},cc2)

Sistemas Operativos Distribuidos Fernando Prez Costoya


25 Jos Mara Pea Snchez
Ejemplo

Propiedad de estabilidad: A 1 eenvia_peticin(1,2) B 1 eenvia_peticin(1,2)


memory 2 eenvia_peticin(1,7) 2 eenvia_peticin(1,7)
3 erecibir_peticin(1,2) 3 erecibir_peticin(1,2)
Propiedades de seguridad: 4 eenvia_peticin(2,3) 4 eenvia_peticin(2,3)
[s1] 0|ccd | 1 5 eenvia_tarea(2) 5 eenvia_tarea(2)
[s2] readingno ccd = 6 erecibir_peticin(2,3) 6 erecibir_peticin(2,3)
[s3] head(ccd)=n n memory 7 erecibir_tarea(2) 7 erecibir_tarea(2)
8 erecibir_peticin(1,7) 8 erecibir_peticin(1,7)
Propiedades de vivacidad:
9 eenvia_dato(2) 9 eenvia_tarea(3)
c1c 10erecibe_dato(2) 10eenvia_dato(2)
cc1 11eenvia_tarea(3) 11erecibe_dato(2)
c2c 12eenvia_respuesta(1,2) 12eenvia_respuesta(1,2)
cc2 13erecibe_respuesta(1,2) 13erecibe_respuesta(1,2)
14erecibir_tarea(3) 14erecibir_tarea(3)
Sistemas Operativos Distribuidos Fernando Prez Costoya
26 Jos Mara Pea Snchez
Ejemplo
A Cc1
1 Ccd {3}
C1c
cache disk
Cdc
C2c
2
Cc2

Instante 13:
Estado:
s=( p1{} , p2{} , pc{memory={2},jobs={7}} , pd={reading=no} )
Canales:
ccd={3}
Sistemas Operativos Distribuidos Fernando Prez Costoya
27 Jos Mara Pea Snchez
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 Prez Costoya
28 Jos Mara Pea Snchez
Sistemas Operativos Distribuidos

Exclusin Mutua

Algoritmos de
Exclusin Mutua
Exclusin Mutua

Mecanismo de coordinacin entre varios procesos concurrentes


a la hora de acceder a recursos/secciones compartidas.

Las soluciones definidas para estos problemas son:


Algoritmos centralizados.
Algoritmos distribuidos.
Algoritmos basados en marcas de tiempo.

Problemtica:
No existen variables compartidas
Riesgo de interbloqueos
Riesgo de inanicin
Sistemas Operativos Distribuidos Fernando Prez Costoya
30 Jos Mara Pea Snchez
Exclusin Mutua

Funciones bsicas de exclusin mutua:


enter(): Acceso a la regin critica (bloqueo).
operations(): Manipulacin de los recursos compartidos.
exit(): Liberacin del recurso (despierta a procesos en espera).

Propiedades:
Seguridad: Como mximo un proceso puede estar ejecutado en la
seccin crtica a la vez.
Vivacidad: Eventualmente se producen entradas y salidas en la
seccin crtica.
Ordenacin: Los procesadores acceden a la regin crtica en base a
unos criterios de ordenacin (causalidad temporal/Lamport).

Sistemas Operativos Distribuidos Fernando Prez Costoya


31 Jos Mara Pea Snchez
Exclusin Mutua

La evaluacin de los algoritmos de exclusin mutua se evala en


base a los siguientes factores:
Ancho de banda: Proporcional al nmero de mensajes transmitidos.
Retardo del cliente: En la ejecucin de cada una de las operaciones
enter()y en cada operacin exit().
Throughput del sistema: Ratio de acceso al recurso por una batera
de procesos que lo solicitan. Evala el retardo de sincronizacin
entre clientes.
Tolerancia a fallos: Comportamiento del algoritmo ante diferentes
modalidades de fallo.

Sistemas Operativos Distribuidos Fernando Prez Costoya


32 Jos Mara Pea Snchez
Exclusin Mutua Centralizado

El algoritmo ms simple:
Los clientes solicitan el acceso a un elemento de control que
gestiona la cola de peticiones pendientes.
Tres mensajes: enter, exit y OK .
No cumple necesariamente la propiedad de ordenacin.

0 1 2 0 1 2 0 1 2

enter exit
enter OK
OK No hay respuespuesta
(bloquea al cliente)

C C C

Cola de Espera Cola de Espera Cola de Espera


1 1 2 2
Sistemas Operativos Distribuidos Fernando Prez Costoya
33 Jos Mara Pea Snchez
Exclusin Mutua Centralizado

Rendimiento:
Ancho de banda:
El acceso al recurso implica dos mensajes (aunque el recurso est
libre).
Retardo del cliente:
enter(): El retardo de transmisin de los dos mensajes.
exit(): Con comunicacin asncrona no implica retraso en cliente.
Throughput del sistema:
La finalizacin de un acceso a la regin critica implica un mensaje de
salida y un OK al siguiente proceso en espera.
Tolerancia a fallos:
La cada del elemento de control es crtica (alg. de eleccin).
La cada de los clientes o la perdida de mensajes se puede solucionar
por medio de temporizadores.
Sistemas Operativos Distribuidos Fernando Prez Costoya
34 Jos Mara Pea Snchez
Exclusin Mutua Distribuida

Algoritmos distribuido de paso de testigo:


Se distribuyen los elementos en un anillo lgico.
Se circula un token que permite el acceso a la regin critica.
El token se libera al abandonar la regin.
No cumple la propiedad de ordenacin

token

Sistemas Operativos Distribuidos Fernando Prez Costoya


35 Jos Mara Pea Snchez
Exclusin Mutua Distribuida

Rendimiento:
Ancho de banda:
El algoritmo consume ancho banda de forma continua.
Retardo del cliente:
La entrada en la seccin critica requiere de 0 a N mensajes.
La salida slo implica un mensaje.
Throughput del sistema:
La entrada del siguiente proceso tras la salida del que ocupa la regin
critica implica de 1 a N mensajes.
Tolerancia a fallos:
Perdida del token: Deteccin y regeneracin
Cada de un elemento del anillo: Reconfiguracin del anillo.

Sistemas Operativos Distribuidos Fernando Prez Costoya


36 Jos Mara Pea Snchez
Exclusin Mutua con Relojes Lgicos

Algoritmo de Ricart y Agrawala: Usa relojes lgicos y broadcast


Pasos:
Un proceso que quiere entrar en seccin crtica (SC) enva mensaje
de solicitud a todos los procesos.
Cuando un proceso recibe un mensaje
Si receptor no est en SC ni quiere entrar enva OK al emisor
Si receptor ya est en SC no responde
Si receptor desea entrar, mira marca de tiempo del mensaje:
Si menor que marca tiempo de su mensaje de solicitud: enva OK.
En caso contrario ser l el que entre.
Cuando un proceso recibe todos (N-1) los mensajes puede entrar.
Garantiza todas las propiedades incluida ordenacin

Sistemas Operativos Distribuidos Fernando Prez Costoya


37 Jos Mara Pea Snchez
Exclusin Mutua con Relojes Lgicos
23 WANTED
23

1
2
OK

23
WANTED 3
21

Los procesos 1 y 3 quieren acceder a la seccin crtica.


Los relojes lgicos son respectivamente 23 y 21.
Sistemas Operativos Distribuidos Fernando Prez Costoya
38 Jos Mara Pea Snchez
Exclusin Mutua con Relojes Lgicos

Rendimiento:
Ancho de banda:
El protocolo consume 2(N-1) mensajes. N-1 para la peticin y N-1
respuestas. Si existen comunicacin multicast slo N mensajes.
Retardo del cliente:
La entrada en la seccin critica requiere de N-1 mensajes.
La salida no implica ningn mensaje.
Throughput del sistema:
Si dos procesos compiten por el acceso a la seccin critica ambos
habrn recibido N-2 respuestas. El de menor reloj tendr la respuesta
del otro. Al salir ste el siguiente se indicar con slo 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 Prez Costoya
39 Jos Mara Pea Snchez
Algoritmos de Votacin

Algoritmo de Maekawa: Algoritmos de votacin.

Anlogo al algoritmo de relojes lgicos pero reduce el nmero de


mensajes:
El procesador elegido es aquel que obtiene la mitad ms 1 votos.
Cada procesador es consultado sobre la eleccin emitiendo un voto.
Para reducir el nmero de mensajes cada uno de los procesadores
que intentan acceder a la seccin critica tiene un distrito (Si), tal que:
Si Sj para todo 1i,jN
De esta forma slo se necesitan N mensajes.

Sistemas Operativos Distribuidos Fernando Prez Costoya


40 Jos Mara Pea Snchez
Algoritmos de Votacin

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 Prez Costoya
41 Jos Mara Pea Snchez
Otras Variantes

Para solucionar los problemas de interbloqueo de los algoritmos


de acceso a regiones crticas en base a mecanismos de votacin
tradicionales (Maekawa) existen otras alternativas:

Saunders: Algoritmos de votacin con marcas de tiempo:


Previene problemas de interbloqueo entre 3 o ms procesos.
Permite retirar votos si la nueva peticin tiene una marca de tiempo
menor.

Sistemas Operativos Distribuidos Fernando Prez Costoya


42 Jos Mara Pea Snchez
Sistemas Operativos Distribuidos

Problemas de
Consenso
Algoritmos de Eleccin
Consenso & Acuerdo
Algoritmos de Eleccin

Son algoritmos diseados para problemas en los cuales uno de


los procesos ha de realizar una tarea especial:
Eleccin de un coordinador.

Estos mecanismos se activan tambin cuando el coordinador


ha fallado.

Objetivo: Eleccin nica

Sistemas Operativos Distribuidos Fernando Prez Costoya


44 Jos Mara Pea Snchez
Algoritmo del Matn

Objetivo
Elige al procesador vivo con un ID mayor

Proceso ve que coordinador no responde. Inicia una eleccin:


Enva mensaje de ELECCIN a procesos con ID mayor
Si ninguno responde: Se hace nuevo coordinador
Manda mensajes COORDINADOR a procesadores con ID menor
Si alguno responde con mensaje OK abandona la eleccin

Si procesador recibe ELECCIN:


Si tiene ID menor, entonces responde OK e inicia eleccin (si todava
no lo haba hecho).
Sistemas Operativos Distribuidos Fernando Prez Costoya
45 Jos Mara Pea Snchez
Algoritmo del Matn

1 1 1
2 5 2 5 2 5

n
Eleccin 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

Sistemas Operativos Distribuidos Fernando Prez Costoya


46 Jos Mara Pea Snchez
Algoritmos en Anillo

Sobre un anillo lgico de procesos se emite un mensaje de


eleccin.

Si un proceso recibe el mensaje:


Si el ID del mensaje es menor que el suyo, lo retransmite con el
suyo.
Si es mayor lo retransmite como tal.
Si es igual, entonces no retransmite y es el coordinador.

Sistemas Operativos Distribuidos Fernando Prez Costoya


47 Jos Mara Pea Snchez
Algoritmo de Invitacin

Problemtica de los algoritmos anteriores:


Se basan en timeouts: Retrasos de transmisin pueden causar la
eleccin de mltiples lideres.
La perdida de conexin entre dos grupos de procesadores puede
aislar permanentemente los procesadores.

Algoritmo de Invitacin, caracterstica:


Definicin de grupos de procesadores con lder nico.
Deteccin y agregacin de grupos.
Reconocimiento por parte del lder de los miembros del grupo.

Sistemas Operativos Distribuidos Fernando Prez Costoya


48 Jos Mara Pea Snchez
Algoritmo de Invitacin
L
Pasos: 2 L
Si un procesador detecta la invitation 3
L
5
perdida del lder, entonces se 1 invitation

declara lder y forma su 4


propio grupo.
L
Peridicamente el lder de 2 L
accept 3 invitation
cada grupo busca otros 5
L
lderes de otros grupos. 1 accept invitation
4
Dos grupos se unen por
medio de mensajes de L
aceptacin: 2 L
3
Como respuesta a mensajes [1] accept 5
L
de invitacin. 1 [2] invitation
De forma explcita. 4

Sistemas Operativos Distribuidos Fernando Prez Costoya


49 Jos Mara Pea Snchez
Problemas de Consenso

Presentes en tareas en las cuales varios procesos deben


ponerse de acuerdo en una valor u operacin a realizar.
Problema de consenso general: Los procesos intercambian
candidatos y cada elemento elige el mayoritario. Debe ser comn.
Consistencia interactiva: Cada proceso aplica un valor diferente y se
debe identificar el vector de valores usado por cada proceso.
Problema de los generales bizantinos: Que pasa si un proceso
transmite valores diferentes a distintos procesos?

Los procesos del sistema pueden encontrase en dos estados:


Correcto: estado vlido.
Incorrecto: procesador cado o funcionando anmalamente.

Sistemas Operativos Distribuidos Fernando Prez Costoya


50 Jos Mara Pea Snchez
Problema de Consenso General

Condiciones:
Terminacin: 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 vlido.
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
Cado
Sistemas Operativos Distribuidos Fernando Prez Costoya
51 Jos Mara Pea Snchez
Consistencia Interactiva

Condiciones:
Terminacin: Cada proceso correcto fija un vector valores.
Acuerdo: El vector decidido es igual para todos los procesos correctos
Integridad: La posicin 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)
Cado
Sistemas Operativos Distribuidos Fernando Prez Costoya
52 Jos Mara Pea Snchez
Generales Bizantinos

Error bizantino: Un proceso genera valores de forma arbitraria.


TRAIDOR
ataque C retirada ataque C ataque

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 Prez Costoya
53 Jos Mara Pea Snchez
Sistemas Operativos Distribuidos

Transacciones
Distribuidas
Operaciones Atmicas
Two-Phase Commit
Transacciones

Conjuntos de operaciones englobadas dentro de un bloque cuya


ejecucin es completa.

Cumplen las propiedades ACID:


Atomicity (Atomicidad): La transaccin se realiza completa o no se
realiza nada.
Consistency (Consistencia): Los estados anterior y posterior a la
transaccin son estados estables (consistentes).
Isolation (Aislamiento): Los estados intermedios de la transaccin
son slo visibles dentro de la propia transaccin.
Durability (Durabilidad): Las modificaciones realizadas por una
transaccin completada se mantienen.

Sistemas Operativos Distribuidos Fernando Prez Costoya


55 Jos Mara Pea Snchez
Transacciones

La gestin de transacciones admite tres operaciones:


beginTransaction(): Comienza un bloque de operaciones
que corresponden a una transaccin.
endTransaction(): Concluye el bloque de operaciones que
conforman la transaccin. Todas las operaciones se completan.
abortTransaction(): En cualquier punto se aborta la
transaccin y se regresa al estado anterior al comienzo de
transaccin.

Otra condicin para abortar la transaccin es debido a errores.

Sistemas Operativos Distribuidos Fernando Prez Costoya


56 Jos Mara Pea Snchez
Transacciones Concurrentes

Se dispone de tres cuentas corrientes A, B y C con saldos $100,


$200 y $300 respectivamente.

Las operaciones sobre una cuenta son:


balance=A.getBalance(): Obtener el saldo.
A.setBalance(balance): Modificar el saldo.
A.withdraw(amount): Retirar una cierta cantidad.
A.deposit(amount): Deposita una cierta cantidad.

Sistemas Operativos Distribuidos Fernando Prez Costoya


57 Jos Mara Pea Snchez
Transacciones Concurrentes

Actualizacin 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

Sistemas Operativos Distribuidos Fernando Prez Costoya


58 Jos Mara Pea Snchez
Transacciones Concurrentes

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

Sistemas Operativos Distribuidos Fernando Prez Costoya


59 Jos Mara Pea Snchez
Transacciones Concurrentes

La problemtica de las transacciones concurrentes se debe a:


Operaciones de lectura y escritura simultnea.
Varias operaciones de escritura simultnea.

La alternativa es la reordenacin de las operaciones a lo que se


denominan operaciones secuenciales equivalentes.
Los mtodos de resolucin aplicados son:
Cerrojos (Locks): Aplicados sobre los objetos afectados.
Control de concurrencia optimista: Las acciones se realizan sin
verificacin hasta que se llega a un commit.
Ordenacin en base a marcas de tiempo.

Sistemas Operativos Distribuidos Fernando Prez Costoya


60 Jos Mara Pea Snchez
Cerrojos

Cada objeto compartido por dos procesos concurrentes tiene


asociado un cerrojo.
El cerrojo se cierra al comenzar el uso del objeto.
El cerrojo se libera al concluir la operacin.

El uso de cerrojos puede ser definido a diferentes niveles del


objeto a controlar (niveles de granularidad).
Modelos de cerrojo:
Lectura
Escritura
Los cerrojos son susceptibles de sufrir interbloqueos.

Sistemas Operativos Distribuidos Fernando Prez Costoya


61 Jos Mara Pea Snchez
Cerrojos

Actualizacin 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 Prez Costoya
62 Jos Mara Pea Snchez
Interbloqueos

Un interbloqueo se produce cuando varios procesos compiten


por cerrojos de forma cclica:
Deteccin de interbloqueos: Grafos de espera.

A
T U
B

Prevencin de interbloques: Cierre de todos los cerrojos de una


transaccin antes de comenzar (Poco eficiente).
Resolucin de interbloqueos: Lo ms habitual es por medio de
Timeouts y abortando la transaccin propietaria del cerrojo.
Sistemas Operativos Distribuidos Fernando Prez Costoya
63 Jos Mara Pea Snchez
Control de Concurrencia Optimista

Muy pocas operaciones concurrentes tiene conflictos entre s.

Divisin de una operacin en:


Fase de trabajo: Los objetos usados por la transaccin pueden ser
copiados en valores tentativos. Una lectura tome este valor si
existe sino el ltimo valor validado. Las escrituras se realizan
siempre sobre los valores tentativos.
Fase de validacin: Al cerrar la transaccin se verifica colisiones con
otras transacciones.
Fase de actualizacin: Los valores tentativos son copiados como
valores validados.

Sistemas Operativos Distribuidos Fernando Prez Costoya


64 Jos Mara Pea Snchez
Control de Concurrencia Optimista
Trabajo Validacin Actualizacin
T1
T2
T3
T4

Validacin:
Validacin hacia atrs: Se anula una transaccin si otra transaccin
activa escribe un valor que sta lee.
Validacin hacia delante: Todos los procesos de escritura realizados
anulan a las transacciones que los lean.
Problemtica:
Si la fase de validacin falla la transaccin se aborta y se reinicia.
Puede causar inanicin.
Sistemas Operativos Distribuidos Fernando Prez Costoya
65 Jos Mara Pea Snchez
Transacciones Distribuidas

Transacciones que afectan de forma atmica a objetos


residentes en varios servidores.
Uso principal: transacciones distribuidas
Cuando termina la transaccin (end-transaction):
Si todos los procesadores implicados estn de acuerdo, se
compromete
Si algn procesador quiere abortarla o est cado, se aborta

Protocolo clsico two-phase-commit (2PC)


Proceso que ejecuta transaccin acta de coordinador
Requiere almacenamiento estable: (nunca pierde la infor.)
Uso de dos discos: se escribe primero en uno y luego en otro

Sistemas Operativos Distribuidos Fernando Prez Costoya


66 Jos Mara Pea Snchez
Two-Phase Commit

Mensajes intercambiados en two-phase commit:


canCommit?(): El coordinador consulta a los servidores.
doCommit(): El coordinador solicita a los servidores el
procesamiento de las modificaciones.
doAbort(): El coordinador indica a los servidores que la
operacin se aborta.
haveCommitted(): El servidor indica que ha completado la
operacin.
getDecision(): El servidor indica si puede realizar la accin.

Sistemas Operativos Distribuidos Fernando Prez Costoya


67 Jos Mara Pea Snchez
Two-Phase Commit
Coordinador:
Escribir canCommit?() en mem. estable P0 P1 P2
Mandar a subordinados canCommit?()
canCommit?
Recoger las respuestas getDecision()
Si todos ok => doCommit()
Si alguno abort o no responde=>doAbort()
Escribir resolucin en mem. estable getDecision(ok) getDecision(ok)
Mandar resolucin

doCommit

Hacer los cambios


haveCommitted permanentes

haveCommitted

Sistemas Operativos Distribuidos Fernando Prez Costoya


68 Jos Mara Pea Snchez
Two-Phase Commit

Subordinados: P0 P1 P2
Recibir canCommit?()
canCommit?
Decidir respuesta y grabar en mem.estable
Mandar respuesta: getDecision()
Recibir resolucin
Escribir resolucin en mem. estable getDecision(ok) getDecision(ok)
Llevar a cabo resolucin:
doCommit()=> hacer cambios permanentes
doAbort() => deshacer cambios doCommit

Hacer los cambios


haveCommitted permanentes

haveCommitted

Sistemas Operativos Distribuidos Fernando Prez Costoya


69 Jos Mara Pea Snchez
Fallos en 2PC

Buena tolerancia a fallos


Recuperacin despus de cada: consulta mem. estable
Recuperacin despus de cada de un subordinado:
Si encuentra en mem. estable la respuesta pero no la resolucin:
pregunta a coordinador cul ha sido la resolucin
Si encuentra en mem. estable la resolucin:
la lleva a cabo
Recuperacin despus de cada de coordinador:
Si encuentra en mem. estable canCommit?()pero no resolucin:
manda a los subordinados mensajes canCommit?()
Si encuentra en mem. estable la resolucin:
manda a los subordinados mensajes con la resolucin

Sistemas Operativos Distribuidos Fernando Prez Costoya


70 Jos Mara Pea Snchez
Three-Phase Commit

Existe una variante del 2PC denominada Three-Phase Commit

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()

Sistemas Operativos Distribuidos Fernando Prez Costoya


71 Jos Mara Pea Snchez