Sincronizaci

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) aHi(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
3
p2
1
5
p3
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) lt (Tj,j) si Ti lt Tj o i lt 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 Vij,
  j 1,2,3...N
• Cada vez que el proceso pi produce un evento
  actualiza Vii
• 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 Vjk max(Vik,Vjk) para
  k 1...N

10
Relojes Vector

• Se puede definir un orden entre los vectores de
  la siguiente forma
• V V ssi Vj Vj para j 1...N
• V lt V ssi Vj lt Vj para j 1...N
• V lt V ssi Vj lt Vj y hay al menos un k
  para el cual Vk lt Vk
• Problema el tráfico es proporcional a N

(1,0,0)
(2,0,0)
p1
(2,2,0)
(2,1,0)
p2
(1,0,0)
(2,2,2)
p3
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

s3
s1
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

s3
s1
s2
con
req
D.m
mc
sup
D.m
19
Problema 2 latecomer recibe 2 veces la
modificación
s3
s1
s2
con
mc
D.m
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 ltT,pigt 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 requests timestamp
• wait until (number of received replies (N-1))
• state HELD
• Al recibir un mensaje de request ltTj,Pjgt
• if (state HELD or (state WANTED and (T, pi) lt
  (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

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 ltT,pigt 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 requests timestamp
• wait until (number of received replies (K-1))
• state HELD
• Al recibir un mensaje de request ltTj,Pjgt
• 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

• 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