Sincronizacion de Procesos Distribuidos Cc 50 h otoo

Sincronizacion de Procesos Distribuidos Cc 50 h otoño 2003

Sincronización de Relojes • Es importante para sincronizar eventos en sistemas distribuidos (transacciones) • Consistencia en datos replicados • El reloj de un sistema se peude representar por Ci(t) = a*Hi(t) + b en que Hi(t) es una medida de tiempo dada por un hardware

El método de sincronización de Christian • Se basa en la observación que en un período corto de tiempo, los mensajes de ida en internet se demoran casi lo mismo que los de vuelta mr cliente mt Servidor de tiempo

El método de sincronización de Christian • Si se llama T(mr) al tiempo en que fue mandado el mensaje y T(mt) al del recibido, y que t es el tiempo que se recibió en mt, se puede estimar que el timestamp se debe poner en t + (T(mt)-T(mr))/2 • Esto se puede comparar con lo siguiente si se conoce el tiempo mínimo que puede tardar una viaje en redondo en la red T(rd) min T(mr) min t T(mt)

Tiempos lógicos • Se trata de lograr sincronización interna, es decir relativa entre los procesos • Se basan en dos principios: – Si dos eventos ocurrieron en un mismo proceso pi (i = 1. . N) entonces el proceso pi puede determinar con exactitud cual ocurrió antes y cual despues – Cuando un mensaje es enviado entre procesos entonces el evento de mandarlo ocurrió necesariamente antes que el de recibirlo

Algoritmo de Lamport • Un reloj lógico es un contador monotónicamente creciente, cuyo valor absoluto no es importante • Cada proceso pi tiene su propio reloj lógico Li que usa para ponerle el timestamp a los eventos • Llamemos el timestamp del evento e en pi Li(e) y llamamos L(e) si no nos importa qué proceso le dio el valor

Algoritmo de Lamport • Cada proceso pi incrementa en uno su reloj Li cada vez que ocurre un evento • Cuando un proceso manda un evento, le incluye el valor t = Li en el mensaje (m, t) • Cuando un proceso pj recibe un mensaje ajusta su reloj con el valor Lj = max(Lj, t) y luego suma 1 para reflejar el evento de recibo de mensaje • Con esto se puede ordenar relativamente bien las cadenas de eventos p 1 p 2 p 3 1 2 3 1 4 5

Ordenamiento total lógico • Se puede dar que pares distintos de eventos tengan el mismo timestamp si fueron generados en procesos distintos. Esto se puede corregir incluyendo la identificación del proceso en el timestamp • Si e 1 ocurrió en el proceso pi en el instante Ti (lógico) y e 2 ocurrió en pj en el instante Tj entonces los timestamps serán (Ti, i) y (Tj, j) respectivamente • Se define (Ti, i) < (Tj, j) si Ti < Tj o i < j • Esto no tiene ningún significado físico

Relojes Vector • Un reloj vector para un sistema de N procesos es un arreglo (o vector) de N enteros. Cada proceso pi guarda un vector propio Vi con valores Vi[j], j= 1, 2, 3. . . N • Cada vez que el proceso pi produce un evento actualiza Vi[i]++ • Cada vez que manda un mensaje envía un “timestamp” que consiste en todo el vector Vi • Cuando un proceso j recibe un mensaje de pi actualiza su vector Vj[k] = max(Vi[k], Vj[k]) para k= 1. . . N

Relojes Vector • Se puede definir un orden entre los vectores de la siguiente forma: • V = V’ ssi V[j] = V’[j] para j = 1. . . N • V <= V’ ssi V[j] <= V’[j] para j = 1. . . N • V < V’ ssi V[j] <= V’[j] y hay al menos un k para el cual V[k] < V’[k] p 1 p 2 p 3 (1, 0, 0) (2, 1, 0) (1, 0, 0) (2, 2, 2) • Problema: el tráfico es proporcional a N

Problemas de exclusión mutua • En sistemas distribuidos el problema de exclusión mutua y locks de recursos es recurrente • En general, estos problemas suceden cuando se comparte una memoria común • En el caso de sistemas distribuidos se trata de compartir un recurso distribuido común • Especialmente difícil es el caso cuando no hay un servidor central y las aplicaciones se deben coordinar entre si, por ejemplo, para ponerse de acuerdo quién puede transmitir cuando (Ethernet)

Regiones Críticas Distr. • Se definen como las normales: un segmento del programa en el cual no pueden haber más de un thread ejecutando. • Modelo: – enter() entrada a la sección crítica – resource. Access() uso de los recursos compartidos en la sección – exit() • ME 1 (safety): a lo más hay un proceso ejecutando en la sección crítica • ME 2 (liveness): requerimientos para entrar a la sección crítica son siempre atendidos tarde o temprano • ME 3 (orden) Si un requerimiento para entrar a la sección crítica pasó antes que otro entonces se les da la entrada en ese orden

Solución con servidor central • Solución clásica definida como monitores • Cada proceso que quiere entrar a la región crítica envía un request • Se le responde con un token, con el cual puede ingresar a la región crítica (note que no tiene por qué estar en el servidor !) • Una vez ejecutada la región crítica el proceso devuelve el token • El servidor debe administrar una cola para que los requerimientos no se pierdan • Ej: implementación con RMI y métodos sincronizados • Claramente se cumplen ME 1 y ME 2 pero no ME 3 • el servidor se convierte en un cuello de botella

Solución con Token ring • También se basa en tener un token para poder entrar a la sección crítica • No tiene por qué reflejar la topología física de la red • El token va viajando en circularmente por los procesos hasta que lo agarra uno que quiere entrar a la sección crítica • También cumple con ME 1 y ME 2 pero no con ME 3 • Consume bastante recurso de red ya que el token se debe siempre ir pasando de un proceso a otro

Con multicast y relojes lógicos • La idea es que cuando un proceso quiere usar una región crítica tiene que tener el permiso de todos los otros • Para ello manda un request por multicast y solo entra a la sección crítica si recibe respuesta afirmativa de todos los demás procesos • Cada proceso debe mantener un reloj del tipo Lamport • Los mensajes de request son de la forma <T, pi> en que T es el timestamp del enviador y pi su id • Cada proceso puede estar en un estado de RELEASED (fuera de la región crítica) WANTED (queriendo entrar) o HELD (dentro de la sección crítica).

El algoritmo de Agrawala • Al inicializar – state = RELEASED • Para entrar a la sección crítica – – – state = WANTED Multicast request to all processes T = request’s timestamp wait until (number of received replies = (N-1)) state = HELD • Al recibir un mensaje de request <Tj, Pj> – if (state = HELD or (state = WANTED and (T, pi) < (Tj, Pj))) queue request from pj without replying else reply immediatly to pj • Para salir de la sección crítica – state = RELEASED – reply to any queued requests

Análisis del algoritmo de Argwala • ME 1: si fuera posible que 2 procesos pi y pj entraran a la sección crítica juntos los procesos deberían haberse contestado mutuamente pero es imposible porque los pares <T, pi> están totalmente ordenados • Por qué se cumple ME 2 y ME 3 ? ?

Algoritmo de voto de Maekawa • Maekawa probó que no es necesario que todos los procesos respondan al request. • Se pueden pedir permisos de subconjuntos siempre y cuando todos los subconjuntos tengan un overlapping de a lo más un proceso • Se puede ver esto como que un proceso pide “votos” para acceder a una sección crítica • un conjunto de procesos Vi para un proceso pi consta de K procesos • pi pertenece al conjunto • la intersección entre cualquiera de dos conjuntos Vi y Vj nunca es vacía • Cada proceso está contenido en M conjuntos

El algoritmo de Maekawa • Al inicializar – state = RELEASED – voted = false • Para entrar a la sección crítica – – – state = WANTED Multicast request to all processes in Vi - {pi} T = request’s timestamp wait until (number of received replies = (K-1)) state = HELD • Al recibir un mensaje de request <Tj, Pj> – if (state = HELD or voted = true ) queue request from pj without replying else reply immediatly to pj voted = true

El algoritmo de Maekawa • Para salir de la sección crítica – state = RELEASED – multicast release to all processes in Vi - {pi} • Al recibir un release de Pj – if (queue of requests is non empty) remove head from queue (say pk request) send reply to pk voted = true else voted = false

Transacciones distribuidas • Transacciones son un conjunto de operaciones que se debes hacer todas o ninguna • Cuando las transacciones se hacen localmente es fácil saber si las condiciones están dadas para efectuarlas • En el caso de las transacciones distribuidas no se comparte memoria común por lo que no se puede efectuar locks y cosas por el estilo • En situaciones de sistemas de varias capas se pueden dar incluso transacciones anidadas

El coordinador de transacciones • Cuando un cliente empieza una transacción se comunica con un coordinador, el cual le da una identificación para la transacción • cada vez que manda una transacción a los servidores manda también la identificación de la transacción y la dirección del coordinador • los servidores se ponen en contacto con el coordinador para mandar su estado y permitir que el coordinador se contacte con ellos • De esta manera el coordinador recoge la información para decidir si se hace o se aborta la transacción coordinador cliente

Protoclo commit de 2 fases • Diseñado para que cualquier participante pueda abortar la transacción • en la primera parte cada participante “vota” por que la transacción se haga o se aborte. • Cuando un participante vota x que se haga no puede abortarla más, por lo que debe asegurarse de tener todos los recursos para llevarla a cabo • Cada participante guarda una copia de los objetos modificados en la transacción y se pone en estado de “preparado” • Si todos los participantes comunican al coordinador que todo está bien y el cliente ordena un commit de la operación esta se hace, de otra manera se aborta • supongamos un modelo de transacciones con los siguientes operaciones – Can. Commit (trans) , do. Commit(trans), do. Abort(trans), have. Commited(trans, participant) get. Decision(trans)

Protoclo commit de 2 fases • Fase 1: – el coordinador manda un can. Commit a cada participante – cuando el participante recibe el can. Commit responde con si o no. Antes de decir si se prepara haciendo copia de todos los objetos. Si vota no se aborta inmediatamente • Fase 2 : – el coordinador recoge todos los votos – si no hay fallas y todos votan si manda un mensaje do. Commit – de otra manera manda un mensaje de do. Abort a todos los que dijeron que si – los participantes que dijeron que si quedan esperando un do. Commit o un do. Abort. Si recibe un do. Commit realiza la operación y manda de vuelta un have. Commited