Sincronización y Latecomers

Presentación del tema: "Sincronización y Latecomers"— Transcripción de la presentación:

1 Sincronización y Latecomers
Lectura

2 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

3 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

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

5 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

6 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

7 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

8 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

9 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

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

11 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

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

13 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

14 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

15 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

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

17 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 s1 s3 s2 con req sup D.m mc D.m D.m

18 Problema 1: latecomer no recibe modificación
S1 no se alcanza a enterar de que S3 también está en la sesión s1 s3 s2 con D.m req mc sup D.m

19 Problema 2 : latecomer recibe 2 veces la modificación
con D.m mc D.m req sup

20 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

21 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

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

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

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

25 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

26 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

27 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

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

29 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

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

31 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

32 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

33 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

34 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

35 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

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

37 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