Sistemas Operativos Distribuidos 4 Sincronización, Concurrencia y Transacciones

Sincronización en Sistemas Distribuidos Sistemas Operativos Distribuidos 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 Cuando estamos desarrollando una aplicación distribuida es importante conocer el orden en el que se producen los eventos. Alto tan tono como la aplicación make puede fallar si no tenemos una visión consistente en el sistema del tiempo. El problema surge en los sistemas distribuidos debido a que no existe un reloj común que marca el mismo tiempo en todos los nodos. Sistemas Operativos Distribuidos 2 4-Sincronización

Sistemas Operativos Distribuidos Tiempo y Estados Relojes Distribuidos Relojes Lógicos Estados Globales

Sincronización de Relojes Físicos Sistemas Operativos Distribuidos 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. A continuación vamos a ver algunos ejemplos de protocolos que podemos utilizar para sincronizar relojes en un sistema distribuido Sistemas Operativos Distribuidos 4 4-Sincronización

Sistemas Operativos Distribuidos 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 El cambio que se introducen en el cliente debe ser gradual, y además no se puede retrasar nunca el reloj en el cliente. Si el reloj genera 100 interrupciones por segundo, lo normal sería que cada interrupción añadiera 10 ms al tiempo. Si hay que reducir la velocidad del reloj porque el cliente está adelantado, se puede añadir sólo 9 ms cada vez hasta que se haga la corrección. De manera similar, el reloj se puede adelantar de manera gradual, sumando 11 ms en cada interrupción del reloj Atrasar un reloj adelantado puede invertir relaciones de causalidad Adelantar uno atrasado falseará medidas de intervalos La corrección deber realizarse de forma gradual Sistemas Operativos Distribuidos 5 4-Sincronización

Sistemas Operativos Distribuidos 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) El algoritmo de Berkeley es pasivo ya que son las máquinas clientes las que solicitan el tiempo al servidor. En el UNIX de Berkeley se sigue un esquema opuesto. En este caso es el servidor de tiempos el que realiza un muestreo periódico del tiempo en todas las máquinas. Sistemas Operativos Distribuidos 6 4-Sincronización

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. Sistemas Operativos Distribuidos 7

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. Sistemas Operativos Distribuidos 8

Sistemas Operativos Distribuidos 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. El echo de que a -> b lo que quiere decir más o menos es que a puede afectar a b. Los dos eventos se dicen que son concurrentes cuando ni a puede afectar a b ni b a a. No es posible establecer entre ellos una relación de causalidad potencial Sistemas Operativos Distribuidos 9 4-Sincronización

Relojes Lógicos (Algoritmo de Lamport) Sistemas Operativos Distribuidos 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. La ordenación temporal de suscesos es fundamental para la operación de la mayoría de los algoritmos distribuidos, como por ejemplo de exclusión mutua o de interbloqueo. La carencia de un reloj común es la restricción principal. La idea es poder decir si el suceso A del nodo I ocurrió antes o después del suceso B del nodo J y ser capaz de llegar de forma consistente a esta conclusión en todos los nodos de la aplicación. Esto es complicado, ya que en primer lugar puede producirse un retardo en el acontecimiento real de un suceso y el momento en que este es observado en algún,otro nodo. En segundo lugar la falta de una sincronización lleva a un desacuerdo en las lecturas de los relojes de los diferentes sistemas. Para superar estos problema Lamport propuso el concepto de relojes lógicos El trabajo sobre sincronización de relojes lógicos surge con Lamport en e1978. El demostró que es posible sincronizar todos los relojes para obtener un estándar de tiempo único sin ambigüedades. Ejemplo del make. Para la mayoría de las aplicaciones basta con que todas los procesos coincidan en la misma hora, pero esta no necesita coincidir con la hora real El orden en el que ocurren los eventos en diferentes procesos puede ser crucial en aplicaciones distribuidas Sistemas Operativos Distribuidos 10 4-Sincronización

Algoritmo de Lamport No sincronizado Sincronizado +1 +1 Sistemas Operativos Distribuidos 11

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. Sistemas Operativos Distribuidos 12

Algoritmo de Mattern y Fidge (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) AF  (100)<(252) (000) B||J  (300)<(025) AND (300)>(025) Sistemas Operativos Distribuidos 13

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). Sistemas Operativos Distribuidos 14

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. Sistemas Operativos Distribuidos 15

Sj Si Cij Lij={m1,..,mk } 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 Sj Cij Si m1 m2 ..... mk Lij={m1,..,mk } Sistemas Operativos Distribuidos 16

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. Sistemas Operativos Distribuidos 17

Cortes Consistentes Corte no consistente Corte consistente p1 p2 p3 p1 m1 m1 m2 m2 m4 no se ha enviado m3 m3 m4 ya ha llegado m4 m4 m5 m5 Sistemas Operativos Distribuidos 18

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. Sistemas Operativos Distribuidos 19

Estados Globales: Propiedades Ejemplo: Un buffer intermedio de almacenamiento. Variables de estado: S:{NO_USABLE,INICIALIZADO} // Estado del buffer T:entero // Tamaño del buffer U:entero // Ocupación del buffer Propiedad de estabilidad: S=INICIALIZADO Propiedad de seguridad: S=NO_USABLE  TU Propiedad de vivacidad: U>0  U<T Sistemas Operativos Distribuidos 20

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. Sistemas Operativos Distribuidos 21

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’.” Sistemas Operativos Distribuidos 22

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. Sistemas Operativos Distribuidos 23

Ejemplo Estados de cada procesador: Ejemplo: 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 Sistemas Operativos Distribuidos 24

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) Sistemas Operativos Distribuidos 25

Ejemplo Propiedad de estabilidad: Propiedades de seguridad: memory Propiedades de seguridad: [s1] 0|ccd |  1 [s2] readingno  ccd = [s3] head(ccd)=n  n  memory Propiedades de vivacidad: c1c   cc1   c2c   cc2   A 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) B 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_tarea(3) 10eenvia_dato(2) 11erecibe_dato(2) 12eenvia_respuesta(1,2) 13erecibe_respuesta(1,2) 14erecibir_tarea(3) Sistemas Operativos Distribuidos 26

Ejemplo A Instante 13: Estado: Canales: 1 2 cache disk Ccd Cdc Cc1 C1c C2c Cc2 {3} Instante 13: Estado: s=( p1{} , p2{} , pc{memory={2},jobs={7}} , pd={reading=no} ) Canales: ccd={3} Sistemas Operativos Distribuidos 27

Ejemplo B Instante 9: Estado: Canales: 1 2 cache disk Ccd Cdc Cc1 C1c C2c Cc2 {3} 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 28

Sistemas Operativos Distribuidos Exclusión Mutua Algoritmos de Exclusión Mutua

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 Sistemas Operativos Distribuidos 30

Exclusión Mutua Funciones básicas de exclusión mutua: Propiedades: 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). Sistemas Operativos Distribuidos 31

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. Sistemas Operativos Distribuidos 32

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. 1 2 1 2 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 33

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. Sistemas Operativos Distribuidos 34

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 Sistemas Operativos Distribuidos 35

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. Sistemas Operativos Distribuidos 36

Exclusión Mutua con Relojes Lógicos Algoritmo de Ricart y Agrawala: Usa relojes lógicos y broadcast Pasos: 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 Sistemas Operativos Distribuidos 37

Exclusión Mutua con Relojes Lógicos WANTED 23 23 1 2 OK 23 3 WANTED 21 Los procesos 1 y 3 quieren acceder a la sección crítica. Los relojes lógicos son respectivamente 23 y 21. Sistemas Operativos Distribuidos 38

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). Sistemas Operativos Distribuidos 39

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 1i,jN De esta forma sólo se necesitan N mensajes. Sistemas Operativos Distribuidos 40

Algoritmos de Votación 1 2 3 4 5 6 7 Componente Decisivo 8 9 10 11 12 13 14 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 41

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. Sistemas Operativos Distribuidos 42

Sistemas Operativos Distribuidos Problemas de Consenso Algoritmos de Elección Consenso & Acuerdo

Algoritmos de Elección Sistemas Operativos Distribuidos 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 Útil cuando necesitamos un coordinador para Sistemas Operativos Distribuidos 44 4-Sincronización

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). Sistemas Operativos Distribuidos 45

Algoritmo del Matón Sistemas Operativos Distribuidos 46

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. Sistemas Operativos Distribuidos 47

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. Sistemas Operativos Distribuidos 48

Algoritmo de Invitación 1 2 3 5 4 L invitation 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. L 2 L 3 invitation accept 5 L 1 accept invitation 4 L 2 L 3 [1] accept 5 L 1 [2] invitation 4 Sistemas Operativos Distribuidos 49

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. Sistemas Operativos Distribuidos 50

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. p2 p2 p1 V=3 p1 D=3 Algoritmo de Consenso Algoritmo de Consenso D=3 V=3 V=2 p4 p4 p3 p3 V=5 Proceso Caído D=3 Sistemas Operativos Distribuidos 51

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 p2 p2 p1 V=3 p1 D=(3,3,5,2) Algoritmo de Consistencia Algoritmo de Consistencia D =(3,3,5,2) V=3 V=2 p4 p4 p3 p3 V=5 Proceso Caído D =(3,3,5,2) Sistemas Operativos Distribuidos 52

Generales Bizantinos G3T Error bizantino: Un proceso genera valores de forma arbitraria. TRAIDOR C C ataque retirada ataque ataque TRAIDOR retirada retirada L L L L ataque ataque G3T ataque=1 retirada=1 ataque=1 retirada=1 TRAIDOR C C ataque ataque retirada ataque ataque TRAIDOR ataque ataque ataque retirada ataque L L L L L L ataque ataque ataque ataque ataque ataque=2 retirada=1 retirada ataque=2 retirada=1 retirada ataque Sistemas Operativos Distribuidos 53

Sistemas Operativos Distribuidos Transacciones Distribuidas Operaciones Atómicas Two-Phase Commit

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. Sistemas Operativos Distribuidos 55

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. Sistemas Operativos Distribuidos 56

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 57

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 Sistemas Operativos Distribuidos 58

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 Sistemas Operativos Distribuidos 59

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. Sistemas Operativos Distribuidos 60

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. Sistemas Operativos Distribuidos 61

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 Lb bal=B.getBalance()$200 • • B.setBalance(bal*1.1)$220 Lb lock lock wait Lb Lb unlock Sistemas Operativos Distribuidos 62

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. A T U B Sistemas Operativos Distribuidos 63

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. Sistemas Operativos Distribuidos 64

Control de Concurrencia Optimista Trabajo Validación Actualización T1 T2 T3 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. Sistemas Operativos Distribuidos 65

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 Sistemas Operativos Distribuidos 66

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. Sistemas Operativos Distribuidos 67

Two-Phase Commit Coordinador: Escribir canCommit?() en mem. estable Mandar a subordinados canCommit?() Recoger las respuestas getDecision() Si todos ok => doCommit() Si alguno abort o no responde=>doAbort() Escribir resolución en mem. estable Mandar resolución P0 P1 P2 canCommit? getDecision(ok) getDecision(ok) doCommit Hacer los cambios haveCommitted permanentes haveCommitted Sistemas Operativos Distribuidos 68

Two-Phase Commit Subordinados: Recibir canCommit?() Decidir respuesta y grabar en mem.estable Mandar respuesta: getDecision() Recibir resolución Escribir resolución en mem. estable Llevar a cabo resolución: doCommit()=> hacer cambios permanentes doAbort() => deshacer cambios P0 P1 P2 canCommit? getDecision(ok) getDecision(ok) doCommit Hacer los cambios haveCommitted permanentes haveCommitted Sistemas Operativos Distribuidos 69

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?() manda a los subordinados mensajes con la resolución Sistemas Operativos Distribuidos 70

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 71