Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

71
Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones

Transcript of Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Page 1: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos

Sincronización, Concurrencia y Transacciones

Sincronización, Concurrencia y Transacciones

Page 2: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos2

Fernando Pérez CostoyaJosé María Peña

Sánchez

Sincronización en Sistemas Distribuidos

Más compleja que en los centralizados

• Propiedades de algoritmos distribuidos:– La información relevante se distribuye entre varias máquinas.– Se toman decisiones sólo en base a la información local.– Debe evitarse un punto único de fallo.– No existe un reloj común.

• Problemas a considerar:– Tiempo y estados globales.– Exclusión mutua.– Algoritmos de elección.– Operaciones atómicas distribuidas: Transacciones

Page 3: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos

Tiempo y Estados

Tiempo y Estados

•Relojes Distribuidos•Relojes Lógicos•Estados Globales

Page 4: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos4

Fernando Pérez CostoyaJosé María Peña

Sánchez

Sincronización de Relojes Físicos

Relojes hardware de un sistema distribuido no están sincronizados.Necesidad de una sincronización para:

– En aplicaciones de tiempo real.– Ordenación natural de eventos distribuidos (fechas de ficheros).

Concepto de sincronización:– Mantener relojes sincronizados entre sí.– Mantener relojes sincronizados con la realidad.

UTC: Universal Coordinated Time– Transmisión de señal desde centros terrestres o satélites.– Una o más máquinas del sistema distribuido son receptoras de señal

UTC.

Page 5: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos5

Fernando Pérez CostoyaJosé María Peña

Sánchez

T 0

I

Cliente

tiem

po

petición

tiempo

Tiempo del manejadorde interrupciones

Servidor de tiem pos

T 1

Algoritmo de Cristian

• Adecuado para sincronización con UTC.• Tiempo de transmisión 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 precisión se pueden hacer varias mediciones y

descartar cualquiera en la que T1-T0 exceda de un límite

Page 6: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos6

Fernando Pérez CostoyaJosé María Peña

Sánchez

3:00 3:00

3:00

3:00

3:25 2:50

3:00 0

+25

-10

3:25 2:50

3:00 +5

-20

+15

3:25 2:50

Algoritmo de Berkeley

• El servidor de tiempo realiza un muestreo periódico de todas las máquinas para pedirles el tiempo.

• Calcula el tiempo promedio y le indica a todas las máquinas que avancen su reloj a la nueva hora o que disminuyan la velocidad.

• Si cae servidor: selección de uno nuevo (alg. de elección)

Page 7: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos7

Fernando Pérez CostoyaJosé María Peña

Sánchez

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 conexión.– Permitir resincronizaciones frecuentes.– Permitir protección ante interferencias del servicio de tiempo.

Organización:– Jerarquía de servidores en diferentes estratos.– Los fallos se solventan por medio de ajustes en la jerarquía.

Page 8: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos8

Fernando Pérez CostoyaJosé María Peña

Sánchez

Protocolo de Tiempo de Red

La sincronización entre cada par de elementos de la jerarquía:– Modo multicast: Para redes LAN. Se transmite por la red a todos los

elementos de forma periódica. Baja precisión.– Modo de llamada a procedimiento: Similar al algoritmo de Cristian. Se

promedia el retardo de transmisión. Mejor precisión.– Modo simétrico: Los dos elementos intercambian mensajes de

sincronización que ajustan los relojes. Mayor precisión.

Los mensajes intercambiados entre dos servidores son datagramas UDP.

Page 9: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos9

Fernando Pérez CostoyaJosé María Peña

Sánchez

Causalidad Potencial

En ausencia de un reloj global la relación causa-efecto (tal como precede a) es una posibilidad de ordenar eventos.

Relación 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 relación es transitiva.

Dos eventos son concurrentes (a || b) si no se puede deducir entre ellos una relación de causalidad potencial.

Page 10: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos10

Fernando Pérez CostoyaJosé María Peña

Sánchez

Relojes Lógicos (Algoritmo de Lamport)

• Útiles para ordenar eventos en ausencia de un reloj común.– Cada proceso P mantiene una variable entera LCP (reloj lógico)– Cuando un proceso P genera un evento, LCP=LCP+1– Cuando un proceso envía 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 lógicos sólo representan una relación de orden parcial.• Orden total entre eventos si se añade el número del

procesador.

Page 11: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos11

Fernando Pérez CostoyaJosé María Peña

Sánchez

Algoritmo de Lamport

No sincronizado Sincronizado

+1

+1

Page 12: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos12

Fernando Pérez CostoyaJosé María Peña

Sánchez

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

Por medio de este mecanismo siempre es posible evaluar si dos marcas de tiempo tienen o no relación de precedencia.

Page 13: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos13

Fernando Pérez CostoyaJosé María Peña

Sánchez

Algoritmo de Mattern y Fidge

(000)

(100) (300) (400) (662)

(276)(262)(010)

(001) (003) (024) (027)

(200)

(026)

(230)

(562)

(242)

(002)

(286)

(025)

(252)(020)

A B C D

E F G

H I J K

AF (100)<(252)

B||J (300)<(025) AND (300)>(025)

Page 14: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos14

Fernando Pérez CostoyaJosé María Peña

Sánchez

Uso de los Relojes Lógicos

La utilización de relojes lógicos (Lamport, Vectoriales o Matriciales) se aplica a:

– Mensajes periódicos de sincronización.– Campo adicional en los mensajes intercambiados (piggybacked).

Por medio de relojes lógicos se pueden resolver:– Ordenación de eventos (factores de prioridad o equitatividad).– Detección de violaciones de causalidad.– Multicast causal (ordenación de mensajes).

Page 15: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos15

Fernando Pérez CostoyaJosé María Peña

Sánchez

Estados Globales

• En un sistema distribuido existen ciertas situaciones que no es posible determinar de forma exacta por falta de un estado global:– Recolección de basura: Cuando un objeto deja de ser referenciado

por ningún elemento del sistema.

– Detección de interbloqueos: Condiciones de espera cíclica en grafos de espera (wait-for graphs).

– Detección de estados de terminación: El estado de actividad o espera no es suficiente para determinar la finalización de un proceso.

Page 16: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos16

Fernando Pérez CostoyaJosé María Peña

Sánchez

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

SiC ij

Lij={m1,..,mk }

m1 m2 mk

Sj

Page 17: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos17

Fernando Pérez CostoyaJosé María Peña

Sánchez

Snapshots

El análisis de los estados globales de un sistema se realiza por medio de snapshots: Agregación del estado local de cada componente así como de los mensajes actualmente en transmisión.

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 evaluación de dicho estado.

Page 18: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos18

Fernando Pérez CostoyaJosé María Peña

Sánchez

Cortes Consistentes

p1 p2 p3

m1

m2

m3

m4

m5

m4 ya ha llegado

m4 no seha enviado

p1 p2 p3

m1

m2

m3

m4

m5

Corte no consistente Corte consistente

Page 19: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos19

Fernando Pérez CostoyaJosé María Peña

Sánchez

Estados Globales: Propiedades

El uso de estados globales es aplicable para la definición 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 ejecución del sistema.

La verificación de un sistema/algoritmo distribuido se basa en la definición y cumplimiento de dichas propiedades.

Page 20: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos20

Fernando Pérez CostoyaJosé María Peña

Sánchez

Estados Globales: Propiedades

Ejemplo: Un buffer intermedio de almacenamiento.Variables de estado:

S:{NO_USABLE,INICIALIZADO} // Estado del bufferT:entero // Tamaño del bufferU:entero // Ocupación del buffer

Propiedad de estabilidad:S=INICIALIZADO

Propiedad de seguridad:S=NO_USABLE TU

Propiedad de vivacidad:U>0 U<T

Page 21: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos21

Fernando Pérez CostoyaJosé María Peña

Sánchez

Estados Globales: Propiedades

La evolución de las propiedades de un sistema se estudian por medio las alteraciones producidas por la ejecución 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.

Page 22: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos22

Fernando Pérez CostoyaJosé María Peña

Sánchez

Análisis 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’.”

Page 23: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos23

Fernando Pérez CostoyaJosé María Peña

Sánchez

Análisis 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 conservarían 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.

Page 24: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos24

Fernando Pérez CostoyaJosé María Peña

Sánchez

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

1

2

cache disk

Ccd

Cdc

Cc1

C1c

C2c

Cc2

Page 25: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos25

Fernando Pérez CostoyaJosé María Peña

Sánchez

Ejemplo

Mensajes: M ={1,2,3,...,10}Eventos:

– eenvia_petición(1,n)=(1,{},{},{n},c1c)– eenvia_petición(2,n)=(2,{},{},{n},c2c)– erecibe_petición(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)

Page 26: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos26

Fernando Pérez CostoyaJosé María Peña

Sánchez

Ejemplo

Propiedad de estabilidad:memory

Propiedades de seguridad:[s1] 0|ccd | 1

[s2] readingno ccd =

[s3] head(ccd)=n n memory

Propiedades de vivacidad:c1c

cc1

c2c

cc2

1 eenvia_petición(1,2)

2 eenvia_petición(1,7)

3 erecibir_petición(1,2)

4 eenvia_petición(2,3)

5 eenvia_tarea(2)

6 erecibir_petición(2,3)

7 erecibir_tarea(2)

8 erecibir_petición(1,7)

9 eenvia_dato(2)

10erecibe_dato(2)

11eenvia_tarea(3)

12eenvia_respuesta(1,2)

13erecibe_respuesta(1,2)

14erecibir_tarea(3)

A1 eenvia_petición(1,2)

2 eenvia_petición(1,7)

3 erecibir_petición(1,2)

4 eenvia_petición(2,3)

5 eenvia_tarea(2)

6 erecibir_petición(2,3)

7 erecibir_tarea(2)

8 erecibir_petición(1,7)

9 eenvia_tarea(3)

10eenvia_dato(2)

11erecibe_dato(2)

12eenvia_respuesta(1,2)

13erecibe_respuesta(1,2)

14erecibir_tarea(3)

B

Page 27: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos27

Fernando Pérez CostoyaJosé María Peña

Sánchez

Ejemplo

1

2

cache disk

Ccd

Cdc

Cc1

C1c

C2c

Cc2

A{3}

Instante 13:Estado:

s=( p1{} , p2{} , pc{memory={2},jobs={7}} , pd={reading=no} )

Canales:ccd={3}

Page 28: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos28

Fernando Pérez CostoyaJosé María Peña

Sánchez

Ejemplo

1

2

cache disk

Ccd

Cdc

Cc1

C1c

C2c

Cc2

B{3}

Instante 9:Estado:

s=( p1{} , p2{} , pc{memory= ,jobs={7}} , pd={reading=2} )

Canales:ccd={3} Incumple la propiedad [s2] de

seguridad

Page 29: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos

Exclusión Mutua

Exclusión Mutua

•Algoritmos de Exclusión Mutua

Page 30: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos30

Fernando Pérez CostoyaJosé María Peña

Sánchez

Exclusión Mutua

Mecanismo de coordinación 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.

Problemática:– No existen variables compartidas– Riesgo de interbloqueos– Riesgo de inanición

Page 31: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos31

Fernando Pérez CostoyaJosé María Peña

Sánchez

Exclusión Mutua

Funciones básicas de exclusión mutua:– enter(): Acceso a la región critica (bloqueo).– operations(): Manipulación de los recursos compartidos.– exit(): Liberación del recurso (despierta a procesos en espera).

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

Page 32: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos32

Fernando Pérez CostoyaJosé María Peña

Sánchez

Exclusión Mutua

La evaluación de los algoritmos de exclusión mutua se evalúa en base a los siguientes factores:

– Ancho de banda: Proporcional al número de mensajes transmitidos.– Retardo del cliente: En la ejecución de cada una de las operaciones enter()y en cada operación exit().

– Throughput del sistema: Ratio de acceso al recurso por una batería de procesos que lo solicitan. Evalúa el retardo de sincronización entre clientes.

– Tolerancia a fallos: Comportamiento del algoritmo ante diferentes modalidades de fallo.

Page 33: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos33

Fernando Pérez CostoyaJosé María Peña

Sánchez

0

enter OK

C

1 2

No hay respuespuesta(bloquea al cliente)

0

enter

C

1 2

OK

0

exit

C

1 2

Exclusión Mutua Centralizado

El algoritmo más 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 ordenación.

1Cola de Espera

1Cola de Espera

2Cola de Espera

2

Page 34: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos34

Fernando Pérez CostoyaJosé María Peña

Sánchez

Exclusión 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 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.

Page 35: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos35

Fernando Pérez CostoyaJosé María Peña

Sánchez

Exclusión Mutua Distribuida

Algoritmos distribuido de paso de testigo:– Se distribuyen los elementos en un anillo lógico.– Se circula un token que permite el acceso a la región critica.– El token se libera al abandonar la región.– No cumple la propiedad de ordenación

token

Page 36: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos36

Fernando Pérez CostoyaJosé María Peña

Sánchez

Exclusión Mutua Distribuida

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.

Page 37: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos37

Fernando Pérez CostoyaJosé María Peña

Sánchez

Exclusión Mutua con Relojes Lógicos

Algoritmo de Ricart y Agrawala: Usa relojes lógicos y broadcastPasos:

– Un proceso que quiere entrar en sección crítica (SC) envía mensaje de solicitud a todos los procesos.

– Cuando un proceso recibe un mensaje• Si receptor no está en SC ni quiere entrar envía 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: envía 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 ordenación

Page 38: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos38

Fernando Pérez CostoyaJosé María Peña

Sánchez

Exclusión Mutua con Relojes Lógicos

– Los procesos 1 y 3 quieren acceder a la sección crítica. – Los relojes lógicos son respectivamente 23 y 21.

12

3

2323

21

WANTED

OK

23

WANTED

Page 39: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos39

Fernando Pérez CostoyaJosé María Peña

Sánchez

Exclusión Mutua con Relojes Lógicos

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

Page 40: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos40

Fernando Pérez CostoyaJosé María Peña

Sánchez

Algoritmos de Votación

Algoritmo de Maekawa: Algoritmos de votación.

Análogo al algoritmo de relojes lógicos pero reduce el número de mensajes:

– El procesador elegido es aquel que obtiene la mitad más 1 votos.– Cada procesador es consultado sobre la elección emitiendo un voto.– Para reducir el número de mensajes cada uno de los procesadores

que intentan acceder a la sección critica tiene un distrito (Si), tal que:Si Sj para todo 1i,jN

– De esta forma sólo se necesitan N mensajes.

Page 41: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos41

Fernando Pérez CostoyaJosé María Peña

Sánchez

Algoritmos de Votación

1 2 3 4 5 6 7

8 9 10 11 12 13 14

15 16 17 18 19 20 21

22 23 24 25 26 27 28

29 30 31 32 33 34 35

36 37 38 39 40 41 42

43 44 45 46 47 48 49

Distrito de Si

Distrito de Sj

ComponenteDecisivo

Page 42: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos42

Fernando Pérez CostoyaJosé María Peña

Sánchez

Otras Variantes

Para solucionar los problemas de interbloqueo de los algoritmos de acceso a regiones críticas en base a mecanismos de votación tradicionales (Maekawa) existen otras alternativas:

– Saunders: Algoritmos de votación con marcas de tiempo:• Previene problemas de interbloqueo entre 3 o más procesos.• Permite retirar votos si la nueva petición tiene una marca de tiempo

menor.

Page 43: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos

Problemas de Consenso

Problemas de Consenso

•Algoritmos de Elección•Consenso & Acuerdo

Page 44: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos44

Fernando Pérez CostoyaJosé María Peña

Sánchez

Algoritmos de Elección

Son algoritmos diseñados para problemas en los cuales uno de los procesos ha de realizar una tarea especial:

– Elección de un coordinador.

Estos mecanismos se activan también cuando el coordinador ha fallado.

Objetivo: Elección única

Page 45: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos45

Fernando Pérez CostoyaJosé María Peña

Sánchez

Algoritmo del Matón

Objetivo– Elige al procesador “vivo” con un ID mayor

Proceso ve que coordinador no responde. Inicia una elección:– Envía mensaje de ELECCIÓN 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 elección

Si procesador recibe ELECCIÓN:– Si tiene ID menor, entonces responde OK e inicia elección (si todavía

no lo había hecho).

Page 46: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos46

Fernando Pérez CostoyaJosé María Peña

Sánchez

Algoritmo del Matón

4

21

6

7

0

5

3

Elección

Elección

4

21

6

7

0

5

3

OK

4

21

6

7

0

5

3

Coordinador

Coordinador

4

21

6

7

0

5

3

OK 4

21

6

7

0

5

3

Ele

cció

n

Page 47: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos47

Fernando Pérez CostoyaJosé María Peña

Sánchez

Algoritmos en Anillo

Sobre un anillo lógico de procesos se emite un mensaje de elección.

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.

Page 48: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos48

Fernando Pérez CostoyaJosé María Peña

Sánchez

Algoritmo de Invitación

Problemática de los algoritmos anteriores:– Se basan en timeouts: Retrasos de transmisión pueden causar la

elección de múltiples lideres.– La perdida de conexión entre dos grupos de procesadores puede

aislar permanentemente los procesadores.

Algoritmo de Invitación, característica:– Definición de grupos de procesadores con líder único.– Detección y agregación de grupos.– Reconocimiento por parte del líder de los miembros del grupo.

Page 49: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos49

Fernando Pérez CostoyaJosé María Peña

Sánchez

Algoritmo de Invitación

Pasos:– Si un procesador detecta la

perdida del líder, entonces se declara líder y forma su propio grupo.

– Periódicamente el líder de cada grupo busca otros líderes de otros grupos.

– Dos grupos se unen por medio de mensajes de aceptación:

• Como respuesta a mensajes de invitación.

• De forma explícita.

1

23

5

4

L

LL

invitation

invitation

1

23

5

4

L

LL

invitation

invitation

1

23

5

4

L

LL

[2] invitation

accept

accept

[1] accept

Page 50: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos50

Fernando Pérez CostoyaJosé María Peña

Sánchez

Problemas de Consenso

Presentes en tareas en las cuales varios procesos deben ponerse de acuerdo en una valor u operación a realizar.

– Problema de consenso general: Los procesos intercambian candidatos y cada elemento elige el mayoritario. Debe ser común.

– 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 válido.– Incorrecto: procesador caído o funcionando anómalamente.

Page 51: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos51

Fernando Pérez CostoyaJosé María Peña

Sánchez

Problema de Consenso General

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.

Algoritmo de

Consenso

p1

p3

p2

p4

V=3

V=3

V=5

V=2

Algoritmo de

Consenso

p1

p3

p2

p4

D=3

D=3

D=3

ProcesoCaído

Page 52: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos52

Fernando Pérez CostoyaJosé 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

Algoritmo de

Consistencia

p1

p3

p2

p4

V=3

V=3

V=5

V=2

Algoritmo de

Consistencia

p1

p3

p2

p4

D=(3,3,5,2)

D =(3,3,5,2)

D =(3,3,5,2)

ProcesoCaído

Page 53: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos53

Fernando Pérez CostoyaJosé María Peña

Sánchez

Generales Bizantinos

Error bizantino: Un proceso genera valores de forma arbitraria.

C

L L

ataque retirada

retirada

ataque

TRAIDORC

L L

ataque ataque

retirada

ataque

TRAIDOR

ataque=1retirada=1

ataque=1retirada=1

C

L L

ataqueretirada

retirada

ataque

TRAIDOR

ataque=2retirada=1

L

ataque

ataque retirada

ataque ataque

C

L

ataqueataque

ataque

retirada

TRAIDOR

ataque=2retirada=1

L

ataque

ataque ataque

ataque ataqueL

G3T

Page 54: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos

Transacciones Distribuidas

Transacciones Distribuidas

•Operaciones Atómicas•Two-Phase Commit

Page 55: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos55

Fernando Pérez CostoyaJosé María Peña

Sánchez

Transacciones

Conjuntos de operaciones englobadas dentro de un bloque cuya ejecución es completa.

Cumplen las propiedades ACID:– Atomicity (Atomicidad): La transacción se realiza completa o no se

realiza nada.– Consistency (Consistencia): Los estados anterior y posterior a la

transacción son estados estables (consistentes).– Isolation (Aislamiento): Los estados intermedios de la transacción son

sólo visibles dentro de la propia transacción.– Durability (Durabilidad): Las modificaciones realizadas por una

transacción completada se mantienen.

Page 56: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos56

Fernando Pérez CostoyaJosé María Peña

Sánchez

Transacciones

La gestión de transacciones admite tres operaciones:– beginTransaction(): Comienza un bloque de operaciones

que corresponden a una transacción.– endTransaction(): Concluye el bloque de operaciones que

conforman la transacción. Todas las operaciones se completan.– abortTransaction(): En cualquier punto se aborta la

transacción y se regresa al estado anterior al comienzo de transacción.

– Otra condición para abortar la transacción es debido a errores.

Page 57: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos57

Fernando Pérez CostoyaJosé María Peña

Sánchez

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.

Page 58: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos58

Fernando Pérez CostoyaJosé María Peña

Sánchez

Transacciones Concurrentes

Actualización perdida:bal=B.getBalance()

B.setBalance(bal*1.1)

A.withdraw(bal*0.1)

bal=B.getBalance()

B.setBalance(bal*1.1)

C.withdraw(bal*0.1)

bal=B.getBalance() $200

B.setBalance(bal*1.1) $220

A.withdraw(bal*0.1) $80

bal=B.getBalance() $200

B.setBalance(bal*1.1) $220

C.withdraw(bal*0.1) $280

Page 59: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos59

Fernando Pérez CostoyaJosé María Peña

Sánchez

Transacciones Concurrentes

Recuperaciones inconsistentes:A.withdraw(100)

B.deposit(100)

<suma de saldos>

A.withdraw(100) $0

B.deposit(100) $400

tot=A.getBalance() $0

tot+=B.getBalance() $300

tot+=C.getBalance() $500

Page 60: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos60

Fernando Pérez CostoyaJosé María Peña

Sánchez

Transacciones Concurrentes

La problemática de las transacciones concurrentes se debe a:– Operaciones de lectura y escritura simultánea.– Varias operaciones de escritura simultánea.

La alternativa es la reordenación de las operaciones a lo que se denominan operaciones secuenciales equivalentes. Los métodos de resolución aplicados son:

– Cerrojos (Locks): Aplicados sobre los objetos afectados.– Control de concurrencia optimista: Las acciones se realizan sin

verificación hasta que se llega a un commit.– Ordenación en base a marcas de tiempo.

Page 61: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos61

Fernando Pérez CostoyaJosé María Peña

Sánchez

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 operación.

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.

Page 62: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos62

Fernando Pérez CostoyaJosé María Peña

Sánchez

Cerrojos

Actualización perdida:bal=B.getBalance()

B.setBalance(bal*1.1)

bal=B.getBalance()

B.setBalance(bal*1.1)

bal=B.getBalance()$200

B.setBalance(bal*1.1)$220

bal=B.getBalance()$200

• •

• •

• •

bal=B.getBalance()$200

B.setBalance(bal*1.1)$220

Lb

Lb

Lb

unlock

lock

lock

Lb

wait

Page 63: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos63

Fernando Pérez CostoyaJosé María Peña

Sánchez

Interbloqueos

Un interbloqueo se produce cuando varios procesos compiten por cerrojos de forma cíclica:

– Detección de interbloqueos: Grafos de espera.

– Prevención de interbloques: Cierre de todos los cerrojos de una transacción antes de comenzar (Poco eficiente).

– Resolución de interbloqueos: Lo más habitual es por medio de Timeouts y abortando la transacción propietaria del cerrojo.

T U

A

B

Page 64: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos64

Fernando Pérez CostoyaJosé María Peña

Sánchez

Control de Concurrencia Optimista

Muy pocas operaciones concurrentes tiene conflictos entre sí.

División de una operación en:– Fase de trabajo: Los objetos usados por la transacción 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 validación: Al cerrar la transacción se verifica colisiones con otras transacciones.

– Fase de actualización: Los “valores tentativos” son copiados como valores validados.

Page 65: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos65

Fernando Pérez CostoyaJosé María Peña

Sánchez

Control de Concurrencia Optimista

Trabajo Validación ActualizaciónT1

T2T3

T4

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.

Page 66: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos66

Fernando Pérez CostoyaJosé María Peña

Sánchez

Transacciones Distribuidas

Transacciones que afectan de forma atómica a objetos residentes en varios servidores.Uso principal: transacciones distribuidas

– Cuando termina la transacción (end-transaction):• Si todos los procesadores implicados están de acuerdo, se

“compromete”• Si algún procesador quiere abortarla o está caído, se “aborta”

Protocolo clásico two-phase-commit (2PC)– Proceso que ejecuta transacción actúa de coordinador– Requiere almacenamiento estable: (“nunca” pierde la infor.)

• Uso de dos discos: se escribe primero en uno y luego en otro

Page 67: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos67

Fernando Pérez CostoyaJosé María Peña

Sánchez

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

operación se aborta.– haveCommitted(): El servidor indica que ha completado la

operación.– getDecision(): El servidor indica si puede realizar la acción.

Page 68: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos68

Fernando Pérez CostoyaJosé María Peña

Sánchez

Two-Phase Commit

Coordinador:Escribir canCommit?() en mem. estableMandar a subordinados canCommit?() Recoger las respuestas getDecision() Si todos ok => doCommit() Si alguno abort o no responde=>doAbort() Escribir resolución en mem. estableMandar resolución

P0

canCommit?

doCommit

getDecision(ok)

Hacer los cambiospermanentes

P1 P2

getDecision(ok)

haveCommitted

haveCommitted

Page 69: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos69

Fernando Pérez CostoyaJosé María Peña

Sánchez

Two-Phase Commit

Subordinados:Recibir canCommit?() Decidir respuesta y grabar en mem.estableMandar respuesta: getDecision() Recibir resoluciónEscribir resolución en mem. estableLlevar a cabo resolución:doCommit()=> hacer cambios permanentes doAbort() => deshacer cambios

P0

canCommit?

doCommit

getDecision(ok)

Hacer los cambiospermanentes

P1 P2

getDecision(ok)

haveCommitted

haveCommitted

Page 70: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos70

Fernando Pérez CostoyaJosé María Peña

Sánchez

Fallos en 2PC

• Buena tolerancia a fallos– Recuperación después de caída: consulta mem. estable

• Recuperación después de caída de un subordinado:– Si encuentra en mem. estable la respuesta pero no la resolución:

• pregunta a coordinador cuál ha sido la resolución– Si encuentra en mem. estable la resolución:

• la lleva a cabo

• Recuperación después de caída de coordinador:– Si encuentra en mem. estable canCommit?()pero no resolución:

• manda a los subordinados mensajes canCommit?()– Si encuentra en mem. estable la resolución:

• manda a los subordinados mensajes con la resolución

Page 71: Sistemas Operativos Distribuidos Sincronización, Concurrencia y Transacciones.

Sistemas Operativos Distribuidos71

Fernando Pérez CostoyaJosé María Peña

Sánchez

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