Sincronizacion de Procesos Distribuidos Cc50h 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 mt cliente 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 min T(mr) 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 1 2 p1 4 p2 3 p3 1 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 e1 ocurrió en el proceso pi en el instante Ti (lógico) y e2 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 Problema: el tráfico es proporcional a N 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] Problema: el tráfico es proporcional a N (1,0,0) (2,0,0) p1 (2,2,0) p2 (2,1,0) p3 (1,0,0) (2,2,2)

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 resourceAccess() uso de los recursos compartidos en la sección exit() ME1 (safety): a lo más hay un proceso ejecutando en la sección crítica ME2 (liveness): requerimientos para entrar a la sección crítica son siempre atendidos tarde o temprano ME3 (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 ME1 y ME2 pero no ME3 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 ME1 y ME2 pero no con ME3 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 reply to any queued requests

Análisis del algoritmo de Argwala ME1: 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 eso es imposible porque los pares <T,pi> están totalmente ordenados Por qué se cumple ME2 y ME3 ????

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 CanCommit (trans) , doCommit(trans), doAbort(trans), haveCommited(trans, participant) getDecision(trans)

Protoclo commit de 2 fases el coordinador manda un canCommit a cada participante cuando el participante recibe el canCommit responde con si o no. Antes de decir si se prepara haciendo copia de todos los objetos. Si vota no se aborta inmediatamente Fase2 : el coordinador recoge todos los votos si no hay fallas y todos votan si manda un mensaje doCommit de otra manera manda un mensaje de doAbort a todos los que dijeron que si los participantes que dijeron que si quedan esperando un doCommit o un doAbort. Si recibe un doCommit realiza la operación y manda de vuelta un haveCommited