Bloque 1Bloque 2Bloque 3

Sincronización distribuida

1. Ordenamiento de mensajes
Un aspecto muy importante de la comunicación en grupo es el   ordenamiento de los
mensajes. Se debe tener bien definida una semántica   con respecto al orden de
entrega de los mensajes en un sistema distribuido. 

Se puede garantizar la entrega inmediata de todos los mensajes en el orden  en que
fueron enviados cuando se cumplen las siguientes condiciones:

todos los mensajes para un grupo se deben entregar antes de   comenzar la

entrega de la siguiente serie de mensajes; 
se respeta el mismo orden de todos los mensajes en todos los  receptores. 

Este esquema se conoce como ordenamiento con respecto al tiempo global. 

En los sistemas distribuidos, la comunicación se realiza a través de transferencia de

mensajes.  
Un mensaje
es la información que pasa de un proceso de remitente a un proceso de
destinatario. 

Relojes
El concepto de tiempo es fundamental para nuestra forma de pensar. Deriva   del
concepto más básico del orden en el que ocurren los eventos. Decimos   que algo
sucedió a las 15:15 si ocurrió después de que nuestro reloj leyó las  15:15 y antes de
las 15:16. El concepto del ordenamiento temporal de los   eventos está presente en
nuestro pensamiento acerca de los sistemas. Así,   por ejemplo, en un sistema de
reserva de una aerolínea, especificamos que   una solicitud de reserva debe
concederse si se realiza antes de que se llene  el vuelo.  

En los sistemas centralizados, donde uno o más procesadores comparten un   bus

común, el tiempo no es una gran preocupación. Todo el sistema   comparte la misma
comprensión del tiempo: correcto o incorrecto, es  consistente. Sin embargo, veremos
que este concepto debe reexaminarse   cuidadosamente al considerar los eventos en
un sistema distribuido. 

Relojes físicos

Cada sistema tiene su propio temporizador que controla su reloj. Estos  temporizadores
se basan en la oscilación de un instrumento de cuarzo o en   un circuito integrado
equivalente. Aunque son razonablemente precisos y  estables, no son perfectos. Esto
significa que los relojes se alejarán de la hora  real. Cada temporizador tiene diferentes
características: características que   pueden cambiar con el tiempo, la temperatura,
etcétera. Esto implica que el  tiempo de cada sistema se desviará del tiempo real a una
velocidad diferente  y quizás en una dirección diferente (lenta o rápidamente). 

¿Con qué frecuencia necesitamos volver a sincronizar los relojes? Coordinar   los
relojes físicos entre varios sistemas es posible, pero nunca puede ser   exacto. En
sistemas distribuidos, debemos estar dispuestos a aceptar cierta  desviación del tiempo
“real” en cada reloj. 
Un reloj típico en tiempo real dentro de una computadora tiene un error   relativo de
aproximadamente 10−5. Esto significa que si el reloj está  configurado para 100 tictac
por segundo, deberíamos esperar 360.000 +/- 4  tictac por hora.  

Dado que diferentes relojes pueden desviarse en diferentes direcciones, el  peor de los
casos es que dos relojes en un sistema se desvíen en direcciones  opuestas. En este
caso, la diferencia entre estos relojes puede ser el doble  del error relativo. Usando un
error relativo de ejemplo de 10−5, esto sugiere  que los relojes pueden separarse hasta
8 tictac por hora. Entonces, por   ejemplo, si queremos que todos los relojes en este
sistema estén dentro de  4 tictac, debemos sincronizarlos dos veces por hora. 
A continuación, se presenta una fórmula general que expresa estas ideas: 

maximum_synchronization_interval = maximum_acceptable_difference   /
maximum_drift_rate / 2 

Algoritmo de Cristian: el algoritmo de Cristian es un método para sincronizar

 relojes físicos utilizando un servidor de tiempo. El servidor de tiempo es un  host
especial que contiene el tiempo de referencia, el tiempo que se  considera (más)
correcto. Normalmente, los servidores de tiempo se  sincronizan con otra fuente,
como un servidor de hora UTC basado en un  reloj atómico. 

El algoritmo de Cristian es un mecanismo de extracción del cliente. Los   clientes

preguntan al servidor de hora la hora actual. Cuando se recibe la   respuesta del
servidor, el cliente intenta ajustarlo para el retraso de tránsito  y luego ajusta su propio
reloj. 
Para comprender la razón por la que se necesita el ajuste del tiempo de   tránsito,
recuerda que el servidor de hora responde con la hora actual en el  momento en que
recibió la solicitud, no la hora en que se envió la solicitud  ni tampoco la hora en que la
respuesta fue recibida por el cliente. 

Para poder estimar mejor la hora actual, el host necesita estimar cuánto   tiempo ha
pasado desde que el servidor de hora respondió. Por lo general,   esto se hace
asumiendo que el tiempo del cliente es razonablemente preciso  en intervalos cortos y
que la latencia del enlace es aproximadamente simétrica (la solicitud demora tanto en
llegar al servidor como la respuesta   tarda en regresar). Dados estos supuestos, el
cliente puede medir el tiempo   de ida y vuelta (RTT, por su nomenclatura en inglés,
round-trip time o round trip delay time) de la solicitud utilizando su reloj local, dividir
este tiempo a  la mitad y restar la hora local del resultado. El resultado es una buena
 estimación del error en la hora local.  
En otras palabras: 

local_clock_error = server_timestamp + (response_received_timestamp   -

request_dispatched_timestamp) / 2 
local_clock_error = server_timestamp + (RTT / 2) 

Si se sabe que el servidor tiene una latencia aproximada para responder a   las
solicitudes una vez que las recibe, también se puede hacer un ajuste para  esto: 

local_clock_error = server_timestamp + (RTT - server_latency) / 2

Estas estimaciones pueden mejorarse aún más ajustándose para RTT   inusualmente
grandes. Es probable que los RTT largos sean menos  simétricos, lo que hace que el
error estimado sea menos preciso. Un enfoque  podría ser realizar un seguimiento de
los RTT recientes y repetir las  solicitudes si el RTT parece ser un valor atípico. Otro
enfoque es utilizar un  promedio adaptativo para ponderar la nueva estimación del error
contra el  agregado de los promedios ponderados anteriores: 

avg_clock_error 0 = local_clock_error  
avg_clock_error n = (weight * local_clock_error) + (1 - weight) *  local_clock_error n-1 

Si el reloj local es más lento que el reloj de referencia, el nuevo valor de  tiempo puede
simplemente adoptarse; en general, los relojes pueden   avanzar sin causar muchos
problemas. Pero si el reloj local es rápido,  adoptar una hora anterior probablemente no
sea una buena idea. Si lo hace,  podría revertir el orden aparente de algunos eventos
al dar una marca de  tiempo más baja a un evento que un predecesor. En el caso de un
reloj local  rápido, el reloj debe reducirse, no se debe ajustar la hora. 

Algoritmo de Berkeley: el algoritmo de Berkeley es un enfoque que se aplica  si

no hay un servidor de tiempo disponible. Este enfoque es algo  centralizado. Un
servidor activo sondea todas las máquinas, las ajusta según  el RTT y el tiempo
de servicio (si se conoce), calcula un promedio y luego le   dice a cada servidor
que acelere o ralentice. El tiempo promedio puede ser  una mejor estimación del
tiempo real que el reloj de cualquier host, pero aún se desviará. El período de la
encuesta debe establecerse como estaba   antes para garantizar que la
desviación máxima entre los ajustes sea  aceptable. 
Algoritmo de Berkeley con transmisión: en lugar de sondear, el servidor  activo
podría transmitir a todos los servidores periódicamente. Al final del   mismo
período, podría recopilar los tiempos que recibió, descartar los  valores atípicos,
hacer los mismos ajustes para RTT que antes y luego decirles a los anfitriones
que ajusten sus relojes al igual que con Berkeley o  Cristian. Al final del período,
todo se repite. Al igual que con el enfoque de   Berkeley, el tiempo promedio
puede alejarse del “tiempo real” y el período   debe ser lo suficientemente
pequeño para garantizar un nivel aceptable de  deriva relativa. 
Servidores de tiempo múltiples: si se dispone de varios servidores de  tiempo,
se puede usar un esquema similar al enfoque de Berkeley o la  variación anterior
para ajustar mejor la inexactitud establecida por la  estimación basada en RTT y
permanecer de modo más resistente en caso de  falla. 
Sincronización del mundo real (network time protocol o NTP): la
 sincronización del reloj en el mundo real se basa en técnicas como las dos  que
acabamos de describir, pero a menudo incluye un filtrado estadístico  adicional y
un modelo más complejo para encontrar un servidor de tiempo.   Además, la
seguridad se convierte en una preocupación: es necesario evitar  que un usuario
malintencionado contamine el tiempo de referencia. 

Relojes lógicos

Un reloj lógico es un mecanismo para capturar relaciones cronológicas y  causales en

un sistema distribuido. Los sistemas distribuidos pueden no   tener un reloj global
físicamente síncrono, por lo que un reloj lógico permite   el ordenamiento global de
eventos de diferentes procesos en dichos  sistemas.  

​Los relojes físicos sincronizados son costosos de mantener e   intrínsecamente

inexactos.Como resultado, son una mala elección de   herramientas para este tipo de
trabajo; en cambio, un reloj lógico es una  mejor opción. El propósito de un reloj lógico
no es necesariamente  mantener la misma noción de tiempo que un reloj confiable; en
su lugar, es  mantener un registro de la información relativa al orden de los eventos.

Algunos algoritmos de reloj lógico notables son: 

1. marcas de tiempo de Lamport, que son contadores de software que   aumentan

monótonamente; 
2. relojes vectoriales, que permiten la ordenación parcial de eventos en  un sistema
distribuido; 
3. vectores de versión, réplicas de pedido, según las actualizaciones, en  un sistema
replicado optimista; 
4. matrix clock, una extensión de los relojes vectoriales que también   contiene
información sobre las vistas del sistema de otros procesos. 

Algoritmo de Lamport: el algoritmo de Lamport proporciona una forma de

  garantizar un tiempo lógico consistente entre muchos hosts. Comencemos a
 analizarlo definiendo una relación muy importante entre los eventos, la  relación
de suceso-antes. 

Definición de sucede-antes: 

Cuando se comparan eventos en el mismo host, si el evento a ocurre  antes del

evento b, entonces sucede antes de b. 
Si un host recibe un mensaje enviado por otro host, el envío ocurre  antes de la
recepción. 
Si se produce x en P1 y se produce y en P2 y, por otro lado, P1 y P2  no se han
intercambiado mensajes, se dice que X e Y son  concurrentes. Si este es el caso,
no podemos inferir nada sobre el orden del evento x y el evento y. Ten en cuenta
que esto solo es  cierto si x e y no intercambian mensajes, incluso indirectamente
a  través de terceros (o varios). 
La relación es transitiva: si a sucede antes de b, y b ocurre antes de  c, entonces
a sucede antes de c. 

Utilizamos esta relación para definir nuestro reloj. En lugar de un reloj que  se mantiene
en tiempo real, es básicamente un simple contador que se usa  para etiquetar eventos
de una manera que muestra la relación entre el  suceso y el antes. Estas son las reglas
que se utilizan para actualizar el valor  del reloj lógico en un host: 

El contador se incrementa antes de cada evento. 

En el caso de un envío, el contador se incrementa y luego se envía el  mensaje.
El mensaje debe llevar la nueva marca de tiempo  (incrementada). 
En el caso de una recepción, la acción adecuada depende del valor  de la marca
de tiempo en el mensaje. Si el mensaje tiene una marca  de tiempo más alta que
la del receptor, el reloj lógico del receptor   adopta el valor enviado con el
mensaje. En cualquier caso, el reloj  lógico del receptor se incrementa y se dice
 que el mensaje se recibió   en el nuevo valor del reloj (incrementado). Esto
asegura que los  mensajes se reciban después de que se enviaron y después de
los  eventos anteriores en el host receptor. 

Ordenamiento total con el algoritmo de Lamport: es importante tener en   cuenta

que, como lo hemos descrito antes, el algoritmo de Lamport no   proporciona un
ordenamiento total. Permite que ocurran dos eventos en  dos hosts diferentes al mismo
tiempo. Esto podría descubrirse  posteriormente si estos hosts intercambian mensajes
posteriormente. Para   solucionar este problema, podemos romper estos vínculos
utilizando el ID de host. Es cierto que esta técnica, para romper lazos, los rompe en un
orden  arbitrario que puede no ser consistente con el tiempo del mundo real, pero  esto
podría no importar. Asegura que las marcas de tiempo son únicas. Es   consistente y
ordenado, por lo que podría ser útil para evitar el deadlock o   el livelock. También
podría ser útil para nombrar eventos de forma única. 

Ahora tenemos lo siguiente: 

∙ Lamport_Timestamp (a) < Lamport_Timestamp (b), si a ocurre antes   de b en el

mismo host; 
∙ Lamport_Timestamp (enviar x <Lamport_Timestamp (recv x); ∙ Lamport_Timestamp
(a)! = Lamport_Timestamp (b), si a y b no son el  mismo evento. 

En muchos sentidos, Lamport logical time es débil y en otros es poderoso.

  Esencialmente, es una forma de proporcionar números de secuencia simples   por
host, mientras se mitigan las inversiones de un sistema a otro en la   transmisión de
mensajes. Al hacerlo, proporciona una forma de ordenar  eventos en un solo host y de
ordenar ciertos intervalos, marcados por las   transmisiones de mensajes, entre los
hosts que se comunican. Sin embargo,  lo simple puede ser poderoso. 
Causalidad (potencial) y violaciones de causalidad: se produce una   violación de
causalidad cuando un problema de orden de mensajes hace que  un host realice una
acción basada en información que otro host aún no ha   recibido, pero debería haber
recibido. En este caso, P2 está intentando  invocar un método en P1, porque P2 piensa
que P1 tiene obj. 

Al diseñar sistemas, asumimos que cualquier acción que realice un host  puede verse
afectada por cualquier mensaje que haya recibido   anteriormente. Se requiere
conocimiento específico de la aplicación para   hacer lo contrario. Como resultado,
consideraríamos que la situación   anterior es una posible violación de causalidad,
incluso si el mensaje de P2 a   P1 resultó ser completamente independiente de los
mensajes que recibió. 
Coloquialmente, no distinguimos entre violaciones potenciales de   causalidad y
violaciones de causalidad que tienen consecuencias reales. En  su lugar, las llamamos
violaciones de causalidad, incluso si los mensajes  resultan ser independientes. 

La conclusión es que se produce una violación de causalidad si el envío de   un

mensaje sabe algo que el destinatario de ese mensaje debe saber (ha sido  enviado),
pero no sabe (no ha recibido) en el momento en que se recibe el  mensaje. 

Existen mecanismos de comunicación que evitan las violaciones de  causalidad, pero,

por el momento, la última pregunta que nos preguntamos es: ¿cómo podemos detectar
(después del hecho) que ha ocurrido una  violación de causalidad? 
El tiempo de Lamport no es suficiente para hacer esto, ya que realiza un  seguimiento
del número total de eventos en el sistema. Esto no es útil; en   cambio, necesitamos
una forma de determinar si los mensajes se enviaron y   se recibieron en el mismo
orden. En otras palabras, si recibimos M2 antes  de M1, pero M1 se envió antes de M2,
se produjo una violación de  causalidad (potencial). Lo mismo es cierto si uno o ambos
mensajes llegaron   indirectamente a través de otros hosts. Esta es una de las áreas
donde  nuestro siguiente tema, el tiempo vectorial, se vuelve particularmente útil. 
Vector tiempo lógico: el tiempo lógico vectorial puede usarse para detectar
 violaciones de causalidad después del hecho. Discutamos la hora lógica del  vector y
luego analicemos cómo podemos detectar las violaciones de   causalidad anteriores
comparando la hora local actual con la marca de  tiempo de un mensaje entrante. 

Al igual que con la hora lógica de Lamport, cada host mantiene su propia  noción de la
hora local y la actualiza utilizando las marcas de tiempo  colocadas por el remitente en
los mensajes. Pero, con el tiempo lógico  vectorial, el tiempo contiene más información:
contiene un vector que   representa el estado de cada host. En otras palabras, este
vector no solo  contiene el recuento de eventos para el host, sino que también contiene
los  últimos recuentos de eventos conocidos en cada uno de los demás hosts. 

La única entrada en este vector que se garantiza que está actualizada es la  entrada
que representa al remitente. Por esta razón, es posible que el   receptor tenga una
comprensión más actualizada de la hora lógica en  algunos de los hosts. Este sería el
caso si se enviara un mensaje desde otro  host al remitente, pero el destinatario no lo
ha recibido.
Como resultado, cuando un host recibe un mensaje, fusiona su vector de  tiempo y la
marca de tiempo enviada con el mensaje y selecciona el valor   más alto para cada
elemento. Esto garantiza que el remitente tenga  información que esté, al menos, tan
actualizada como el destinatario. 
A continuación, se muestra un resumen de las reglas para los relojes vector  lógicos: 

En lugar de simplemente mantener nuestro tiempo lógico,   mantenemos un

vector, V[], de modo tal que V[i] representa lo que  sabemos del tiempo lógico en
el procesador i. 
V[mi_id] es nuestro tiempo lógico. 
Enviar V[] vector con cada mensaje. 
Al recibir, fusiona ambos vectores, seleccionando el mayor de los   elementos
correspondientes de cada uno. Luego incrementa el  componente para sí mismo.
Se dice que el evento ocurrió en un  tiempo nuevo (incrementado). 
En el envío, aumenta el componente de tiempo para uno mismo.  Envía el vector
de fecha y hora actualizado con el mensaje. Se dice  que el evento ocurrió en un
tiempo nuevo (incrementado). 

Comparación de marcas de tiempo vectoriales: al comparar marcas de   tiempo

vectoriales, lo hacemos cotejando cada elemento en una marca de   tiempo con el
elemento correspondiente en la otra marca de tiempo: 

Si los elementos correspondientes en dos marcas de tiempo son   idénticos, los

dos eventos son el mismo evento. Las marcas de  tiempo de diferentes eventos
nunca deben ser idénticas. 
Si el evento A ocurre antes que el evento B, entonces cada elemento   de la
marca de tiempo del evento A es menor o igual que el elemento  correspondiente
 en la marca de tiempo del evento B y al menos un   elemento es menor que el
elemento correspondiente en el evento B  de marca de tiempo. 
Si el evento B ocurre antes que el evento A, entonces cada elemento   de la
marca de tiempo del evento A es mayor o igual al elemento  correspondiente en
la marca de tiempo del evento B y al menos un   elemento es mayor que el
elemento correspondiente en el evento B  de marca de tiempo. 
Si dos eventos son concurrentes, tendrán marcas de tiempo mixtas, de manera
que al menos un par de elementos correspondientes será "mayor que" y al
menos un par de elementos correspondiente será "menor que". 

La definición anterior de la comparación de la marca de tiempo del vector  garantiza las

dos propiedades siguientes:
9 
-El evento A "sucede antes" Evento B ==> Vector_Timestamp (Evento   A)
<Vector_Timestamp (Evento B); 
-Vector_Timestamp (Evento A) <Vector_Timestamp (Evento B) ==>  Evento A "sucedió
antes" Evento B. 
Detección de violaciones de causalidad utilizando marcas de tiempo  vectoriales:
podemos detectar una violación de causalidad utilizando   marcas de tiempo
vectoriales, a través de la comparación de la marca de  tiempo de un mensaje recién
recibido con la hora local. Si la marca de tiempo  del mensaje es menor que el vector
de hora local, se ha producido una  violación de causalidad (potencial). 

¿Por qué? Para que la hora local haya avanzado de forma tal que esté  adelantada a la
marca de hora del mensaje recién recibido, un mensaje   anterior debe haber
adelantado la hora local. El remitente de ese mensaje  anterior debe haber recibido el
mensaje recién llegado antes de enviarnos   su mensaje anterior. Así ocurrió una
violación de causalidad (potencial). 

Es cierto que esto no soluciona el problema, pero, al menos, tenemos una  forma de
detectar y registrar el problema. Esto facilitará mucho el  aislamiento y la depuración y
tomará medidas de mitigación para garantizar  que la salida del sistema sea correcta. 
Matriz de relojes lógicos: en realidad, existe otro tipo de reloj lógico, que es  un paso
más amplio que un reloj de vector lógico, a saber: el reloj de matriz  lógica. Al igual que
un reloj de vector, mantiene el tiempo lógico simple para  cada host: un reloj de matriz
mantiene un vector de los relojes de vector  para cada host. 

Cada vez que se intercambia un mensaje, el host de envío nos dice no solo   lo que
sabe sobre el estado global del tiempo, sino también lo que otros  hosts le han dicho
que saben sobre el estado global del tiempo: chismes  confiables. 

Esto es útil en aplicaciones como Checkpointing, Recovery y Garbage  Collection. En

estos casos, tener un límite inferior sobre lo que otro host  sabe puede resultar útil al
permitir la eliminación de objetos inutilizables. En  el caso de Garbage Collection, los
objetos que no son otro objeto pueden  hacer referencia. En el caso de Recovery, logs
o puntos de control ya no son  necesarios.

2. Bloqueos en sistemas distribuidos

Este tipo de bloqueos son peores que los bloqueos en sistemas   monoprocesador,
debido a que son más difíciles de evitar, prevenir, detectar   y solucionar. Uno de los
motivos es que toda la información relevante está  dispersa en muchas máquinas. Los
sistemas gestores de bases de datos  distribuidas son especialmente críticos. 

Algunas de las estrategias para el manejo de los bloqueos en sistemas   distribuidos

son: 

Algoritmo del avestruz (ignorar el problema): el algoritmo de  avestruz es una

estrategia de ignorar problemas potenciales sobre la   base de que pueden ser
extremadamente raros. Se llama así por el  efecto del avestruz, esto es, ocultar la
cabeza en la arena y pretender  que no hay problema. Se utiliza cuando es más
rentable permitir que  ocurra el problema que intentar su prevención.  
Detección: se trata de permitir que ocurran los bloqueos, detectarlos  e intentar
recuperarse de ellos. La detección del bloqueo mutuo es   el proceso de
determinar si existe un interbloqueo e identificar los procesos y recursos
implicados en él. Estos determinan, por lo   general, si existe una espera
circular.  La detección del interbloqueo implica cierto costo extra durante la
 ejecución; por ello, se presenta, así, la cuestión de la costeabilidad,  es decir que
aparece el interrogante de si el costo extra producido   por los algoritmos de
detección del bloqueo mutuo justifica los   ahorros potenciales derivados de la
localización y solución de los  interbloqueos. 
Prevención: se trata de hacer que los bloqueos sean imposibles  desde el punto
de vista estructural. Havender llegó a la conclusión de  que si falta alguna de las
cuatro condiciones necesarias (condición de   exclusión mutua, condición de
espera, condición de no apropiación y   condición de espera circular), no puede
haber un interbloqueo. Este  autor sugiere las siguientes estrategias para negar
varias de esas  condiciones: 

Cada proceso deberá pedir todos sus recursos al mismo  tiempo y no podrá seguir la
ejecución hasta haberlos recibido  todos. 

1. Si a un proceso que tiene recursos se le niegan los demás, ese  proceso deberá
liberar sus recursos y, en caso necesario,   pedirlos de nuevo junto con los
recursos adicionales.
2.   Se impondrá un ordenamiento lineal de los tipos de recursos   en todos los
procesos; es decir, si a un proceso le han sido   asignados recursos de un tipo
específico, en lo sucesivo sólo   podrá pedir aquellos recursos que siguen en el
 ordenamiento. 

Como se observa, Havender presenta tres estrategias y no cuatro,  debido a que estas
están diseñadas para negar una de las  condiciones necesarias (la primera de ellas),
es decir que los procesos  exigen el uso exclusivo de los recursos que requieren. 

Evitarlos: aun cuando se presentan las condiciones para un   interbloqueo, es

posible evitarlo mediante una asignación cuidadosa  de los recursos. El algoritmo
más famoso para evitar el interbloqueo  es el algoritmo del banquero, de Dijkstra.
Su nombre se debe a que   se compara a un banquero que otorga préstamos y
recibe pagos a  partir de una determinada fuente de capital. 
El algoritmo del avestruz merece las mismas consideraciones que en el caso   de
mono-procesador. 
En los sistemas distribuidos resulta muy difícil implantar algoritmos para   evitar los
bloqueos: 

Se requiere saber de antemano la proporción de cada recurso que   necesitará

cada proceso. 
Es muy difícil disponer de esta información en forma práctica. 

Las técnicas más aplicables para el análisis de los bloqueos en sistemas  distribuidos
son: 

Detección. 
Prevención. 

3. Sincronización

En el ámbito de sistemas distribuidos, se conoce como sincronización a las  acciones

que modifican el orden, en forma parcial o total, de un conjunto de   eventos. Este
término hace referencia a tres tipos de problemas distintos y  relacionados entre sí:  

1. Sincronización entre el emisor y el receptor de mensajes.

2. Especificación y control de la actividad común entre procesos  cooperativos.

3. Serialización de accesos concurrentes a objetos compartidos de   múltiples

procesos. 

Un tema de gran importancia es el tiempo y la forma de medirlo, ya que  juega un papel

fundamental en algunos modelos de sincronización. La  complejidad en sincronización
de procesos en los sistemas distribuidos se   relaciona con el hecho de que la
información y el procesamiento se  encuentran en distintos equipos.​​