Sincronización y Latecomers

Lectura

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

Servidor de tiempocliente

mr

mt

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)

T(mr) T(mt)t

min min

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

p1

p2

p3

1

1

2

3 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 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• 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 Np1

p2

p3

(1,0,0)

(1,0,0)

(2,0,0)

(2,1,0) (2,2,0)

(2,2,2)

Una sesión colaborativa• Una sesión colaborativa consiste en varios

procesos compartiendo recursos (por ejemplo, objetos)

• Normalmente un proceso va a iniciar una sesión colaborativa y los demás van a unirse a ella

• Lo importante es que todos los procesos vean a los objetos compartidos en el mismo estado

Estrategias para compartir objetos• Los objetos se pueden compartir de 3 maneras:

– Lo más sencillo es tener un repositorio centralizado de los objetos, todos los procesos sólo tienen referencia a ellos.

– Cada proceso tiene una copia actualizada del objeto. Cuando algún proceso hace una modificación en el objeto debe informarlo a todos los que tienen copia de él.

– Hay procesos que son dueños de los objetos, los demás sólo obtienen referencias a ellos. Cuando un proceso modifica algún objeto le manda un aviso al dueño.

El problema de los latecomers

• Cuando un nuevo miembro se une a la sesión debe obtener un estado actualizado del estado del conjunto de los recursos compartidos

• Una estrategia es hacer un “replay” de todas las modificaciones que han sufrido los objetos compartidos: se gastan muchos recursos y a veces no es posible registrar todos los eventos

• Es más fácil transmitir el estado de los objetos, pero esto puede implicar transmitir demasiada información

DreamObject (la lectura)• El autor del paper propone un sistema que puede

apoyar ambos métodos para compartir objetos, así como también la existencia de objetos totalmente replicados, sólo referenciados ya sea en un repositorio común o distribuidos o una mezcla de ambos

• Esto se apoya en un trabajo previo llamado DereamTeam que maneja las conexiones entre los procesos que quieren compartir objetos

• Esto lo hace a través de un Network Kernel Interface

Como funciona DreamObjects • DreamObjects divide una aplicación colaborativa en objetos que

son datos (invisibles) y objetos de interfaces (visibles)• Para crear una clase de objeto “compartible” , por ejemplo

SampleObject el programador debe implementar la interfaz SharedObject, en la cual se debe definir el atributo MODIFYING_METHODS.

• Este atributo define los métodos de la clase que deberán distribuirse ya que modifican el estado del objeto.

• El sistema entonces genera la clase SampleSubstitute, que es una extensión de SampleObject que agrega las funcionalidades para que el objeto sea compartible según el esquema de DreamObject

Definiendo Políticas del Objeto • En el objeto compartible nuevo se pueden definir distintos esquemas

de distribución de un objeto:– asymetric: en el cual solo el proceso que creó el objeto tiene una copia del dato

(los otros reciben una referencia llamada substitute)– replicated: cada proceso que comparte el objeto tiene una copia de él, por lo

cual puede ejecutar los métodos en forma local– adaptive: el sistema elige la firma de compartir los objetos de modo de hacer

más eficiente el comportamiento del sistema dependiendo de las condiciones del objeto y la red

• Se pueden definir dos tipos distintos de consistencia de para un tipo de objeto que definen cómo se mantendrá consistente un objeto:– Una permite definir explícitamente el floor control del objeto– La otra trata de sacar máximo partido de la concurrencia ejecutando métodos

conflictivos bajo el esquema de exclusión mutua.

Transferencia directa del estado• El paper muestra en el punto 4. Los problemas (y sus

solución) de usar la transferencia directa del estado del objeto para que un latecomer obtenga el estado actual de un un objeto compartido.

• Veamos primero un caso en que todo funciona bien

con

mc

req

supD.m

D.m D.m

s1 s2 s3

Problema 1: latecomer no recibe modificación

con

mcreq

sup

D.m

D.m

s1 s2 s3

• S1 no se alcanza a enterar de que S3 también está en la sesión

Problema 2 : latecomer recibe 2 veces la modificación

con

mc

req

sup

D.mD.m

s1 s2 s3

Solución Propuesta• DreamObjects divide el proceso de unirse a una sesión en 3 etapas:

connection, initial y final

• En la etapa de conexión, el proceso que se une a la sesión establece la conexión con todos los participantes. Desde este momento, los otros procesos incluyen en parte al latecomer como receptor de los mensajes de cambio de estado.

• En la etapa inicial el latecomer requiere un estado inicial del (los) objeto(s) a compartir de un proceso arbitrario. Como los otros procesos siguen su ejecución y pueden modificar el estado del objeto, este estado puede estar obsoleto.

• Por esta razón el latecomer usa la etapa final para balancear el estado recibido con los otros procesos participantes

Etapa de conexión • Cuando un usuario quiere unirse a una sesión tiene que seleccionar desde el session window de DreamTeam una y decidir si se va a sincronizar con replay o por transferencia directa de estado

• Cada sitio (proceso) participante mantiene una lista S de los otros sitios participantes y un reloj lógico (veremos más tarde con detalle). En la etapa de conexión el session manager actualiza la lista S agregando al latecomer slc Después de esto, el latecomer inicia la conexión con todos los otros sitios

• Cada vez que un sitio distribuye un mensaje a los otros, incluye un timestam ts , e incrementa el valor del reloj.

•Un timestamp consiste en el valor actual del reloj del sitio que envía y un identificador del sitio.

•Los timestamps son usados para ordenar totalmente los mensajes (es decir, determinar el orden total en el cual sucedieron)

• Cada sitio al cual se conecta el latecomer manda un timestamp tslc. El latecomer usará esto para determinar en la etapa final si su sesión está obsoleta o no

• Mientras el latecomer no termina su proceso de unión a la sesión guarda los mensajes de modificación de objetos en un buffer

Etapa Inicial• El latecomer selecciona un sitio de soporte ssup como el sitio inicial para recibir el estado de los objetos, para esto le manda un mensaje req

• Sea D el conjunto de objetos a compartir en la sesión. Llamemos Dsup a los objetos que el sitio soporte ssup ya ha transmitido al latecomer y Dlc a los que ya ha transmitido. Entonces D = Dsup+ Dlc

• En en comienzo Dsup= D y Dlc = vacío

• Para los objetos del cual el sitio de soporte no es holder, o para los cuales el latecomers no debe ser un holder el sitio soporte empieza a transmitir los initial representation message, con lo cual el usuario obtiene una referencia al objeto (copia vacía) del objeto,

• Para los demás objetos manda un object support message, que además puede contener referencias a otros objetos, los cuales también son pasados cuidando de no pasar un objeto dos veces (evitar loops)

•Cada sitio mantiene vector de timestamps Hs con la información de las modificaciones que se le han hecho a los objetos que tiene. El sitio soporte envía estas para cada objeto.

Etapa Final• Cuando la etapa inicial está lista el latecomer tiene un estado de los objetos compartidos pero puede estar obsoleta (problema 1)

• Para actualizar los objetos de los cuales es holder le pregunta a todos los participantes si tienen modificaciones a algunos de estos objetos que hayan sucedido antes de que se conectara en la primera etapa a ellos (es decir, modificaciones antes de tslc para cada s) con lo cual “balancea” su estado

• Cada vez que se comunica con un sitio (final support site) en la etapa final, el latecomer pasa un vector de referencias para los objetos del cual no es holder y otro para los cuales si lo es. Además pasa un vector de timestamps con la historia de modificaciones que tiene ya ha recibido de los otros sitios antes del tiempo de conexión con el sitio actual

• El que recibe esta información revisa su historial de modificaciones y para los objetos para los cuales el latecomers es holder manda las modificaciones que no estan en el vector de modificaciones del latecomer con timepo anterior a la conexión (los de tiempo posterior a la conexión están almacenados en el buffer de mensajes)

• Existe todavía un caso en que el latecomer podría no recibir una modificación, que es cuando un sitio realiza una modificación antes que se conecte el latecomer pero que le llega tarde a los otros (fig 6) ¿qué tiene que hacer el final support site?

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– state = RELEASED

– 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 pjvoted = 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• Fase 1:

– 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