Capítulo IV:

Fundamentos teóricos de
computación distribuida
Sincronismo, relojes, c us lid d y consistenci de est dos glob les

Prof. Dr.-Ing. R úl Monge Anw ndter ⧫ 1er semestre 2025

@ Prof. Raúl Monge - 2025

Objetivos del capítulo:

Objetivo general:
• Comprender los fundamentos teóricos de la computación distribuida, especialmente
sobre aspectos de sincronismo y consistencia de un estado distribuido, como base teórica
para resolver problemas complejos en el diseño de sistemas distribuidos

Objetivos de aprendizaje:
1. Comprende los diferentes modelos de sincronismo y coordinación distribuida.
2. Explica los algoritmos de sincronización de relojes de tiempo real de tipo
determinísticos y probabilísticos.
3. Aplica los conceptos de relojes lógicos y vectoriales para resolver problemas de
coordinación y ordenamiento de eventos de una computación distribuida.
4. Analiza correctamente la consistencia de un estado global.
@ Prof. Raúl Monge - 2025 2
a
a
a
 Agenda

1. Coordinación y sincronismo en sistemas distribuidos

2. Sincronización de relojes de tiempo real
3. Causalidad, concurrencia y Relojes lógicos Lamport
4. Relojes vectoriales
5. Estados globales y consistencia
@ Prof. Raúl Monge - 2025 3

4.1 Coordinación y
sincronismo en Sistemas
Distribuidos

@ Prof. Raúl Monge - 2025 4

 Coordinación en Sistemas Distribuidos
Problemas fundamentales de coordinación
Coordinar: “Unir dos o más cosas de manera que formen una unidad o un conjunto armonioso” — [RAE]
• Esto implica alcanzar algún tipo de acuerdo.

1. Sincronización de relojes. Lograr que relojes asociados a diferentes procesos compartan

una base de tiempo común precisa y exacta.
2. Simultaneidad. Hacer que ciertos eventos o acciones ocurran al mismo tiempo en diferentes
procesos del sistema.
3. Exclusión mutua. Garantizar que ciertas acciones no se ejecuten simultáneamente en
diferentes procesos del sistema.
4. Ordenamiento. Ordenar la ocurrencia de ciertos eventos o acciones en diferentes procesos
del sistema, de acuerdo a algún criterio o plan.
5. Consenso. Ponerse de acuerdo entre varios procesos sobre un mismo valor para una
variable o sobre realizar alguna posible acción común.
@ Prof. Raúl Monge - 2025 5

Modelos de sincronismo
Noción de tiempo p r procesos distribuidos y cooper tivos

Modelo asincrónico: No hay garantía de tiempo Modelo sincrónico: Procesos funcionan de forma
sobre la velocidad de ejecución y/o los retardos en la sincronizada y se garantiza límites estrictos en
comunicación; i.e., no existe noción de una medida velocidad de ejecución y/o retardos en la
tiempo. comunicación:
• Entrega de mensajes: Mensajes pueden tardar un • Entrega de mensajes: Se garantiza la entrega de
tiempo arbitrario en entregarse, pero nito. mensajes dentro de un límite de tiempo conocido.
• Velocidad de procesamiento: Procesos pueden • Velocidad de procesamiento: el tiempo que
tardar un tiempo arbitrario en ejecutar los pasos, tarda un proceso en ejecutar un paso está
pero nito. acotado.
• Sincronización de relojes: Relojes reales pueden • Sincronización de relojes: Relojes de procesos
desviarse arbitrariamente. están sincronizados dentro de límites conocidos.
∴ ∄ noción global de tiempo real. ∴ ∃ noción global de tiempo real.
Comentario: Si no se conocen límites de tiempo en un sistema, se debe trabajar en un modelo asincrónico.
@ Prof. Raúl Monge - 2025 6
fi
a
a
fi
 Ejemplo Nº1: Un problema clásico de coordinación distribuida

Suposición:
• Dos procesos A y B se comunican enviándose mensajes por un canal bidireccional.
• Ningún proceso puede fallar.
• Los canales pueden experimentar fallas transitorias, con posible pérdida de algunos mensajes, pero
garantizando su integridad (no se corroen).
Objetivo:
• Encontrar un protocolo para ponerse de acuerdo sobre realizar una de dos posibles acciones u y v, tal que:
• Ambos procesos A y B deciden realizar la misma acción ( u ⊻ v ), o
• No se hace nada (ninguna de las acciones se realiza, por falta de acuerdo).

Comentario: ¡Se trata de un problema de acuerdo entre dos procesos

usando un canal de comunicación no able (modelo de fallas de omisión)!

@ Prof. Raúl Monge - 2025 7

La paradoja de los dos generales

General A General B Condiciones:
• Ataque de ejércitos A y B
debe ser coordinar para tener
éxito y derrotar al enemigo.
Ejército A Mensajero
Ejército B • Mensajeros pueden ser
interceptados (comunicación
no es able)
• Decisión de iniciar un ataque
deber ser por consenso
Enemigos (acuerdo).

Problema: ¿Existirá algún protocolo que permita llegar a un acuerdo a

ambos generales, después de intercambiar un número nito de mensajes?

Fuente: Jim Gray, "Notes on Data Base Operating Systems", Operating Systems, An Advanced Course. Springer, pp. 393–481, 1978.

@ Prof. Raúl Monge - 2025 8

fi
 Demostración de no existencia de tal protocolo
Demostr ción por el bsurdo

• Suposición inicial:

• Se asume que existe un protocolo con un intercambio mínimo de n mensajes.

• Consecuencia:

• Entonces consenso se debe haber alcanzado en mensaje #(n − 1), pues n-ésimo
mensaje se pudo haber perdido.

∴ Existe una contradicción ⟹ ¡No existe tal protocolo!

@ Prof. Raúl Monge - 2025 9

Ejemplo Nº2: Problema de elección de un líder

Con un modelo trivi l de f ll s

Supongamos:
• Sea un conjunto de n procesos P1, P2, ⋯, Pn, donde se debe seleccionar a un líder.
• ∀i : 1 ≤ i ≤ n : Pi tiene un identi cador único uid(i);
∴ identi cadores de nen un ordenamiento total de los procesos en el sistema.
• Todos los procesos comienzan simultáneamente el algoritmo (digamos en t = 0).
• Los procesos y la comunicación son totalmente ables.
Objetivo:
• Diseñar un protocolo donde todos los procesos aprenden la identidad del líder.

@ Prof. Raúl Monge - 2025 10

fi
a
fi
a
a
a
a
 a) Solución en un modelo asincrónico del sistema
ALGORITMO:
• Cada proceso Pi difunde (broadcast) a todos los procesos ( ∀i : 1 ≤ i ≤ n) un mensaje que
contiene su identi cador uid(i).
• Cuando un proceso Pj reciba n mensajes, decide que el líder es aquel proceso Pk con menor uid(k).

CORRECTITUD:
• Cada proceso va eventualmente a recibir exactamente un mensaje por proceso (total: n mensajes),
dado que la comunicación es able y la entrega ocurre en tiempo nito.
∴ Todos los procesos tendrán el mismo conjunto de n mensajes y c/u puede independientemente
elegir al mismo proceso Pk: con menor uid(k); u otro criterio, acordado previamente por todos.

Observación: Nótese que n difusiones de mensajes son requeridas para una elección.
∴ Complejidad en mensajes del algoritmo: ∼ O(n 2)
@ Prof. Raúl Monge - 2025 11

b) Solución en un modelo sincrónico del sistema

RESTRICCIONES DE TIEMPO: Supóngase que T es constante de tiempo conocida, mayor que:
• Mayor retardo para transmitir y entregar un mensaje en el sistema.
• Mayor diferencia de tiempo entre relojes de dos procesos arbitrarios (de ne precisión de sincronismo).
• Todos los procesos comienzan el algoritmo al mismo tiempo (digamos en t = 0).

ALGORITMO:
• Al iniciarse el algoritmo, todo proceso Pi parte un timer y espera hasta que se cumpla alguna de las siguiente condiciones:
(i) Recibe un mensaje de difusión (broadcast) de otro proceso menor y detiene su timer.
(ii) Si ha transcurrido tiempo T ⋅ uid(i) en su reloj (i.e., ocurre timeout), entonces procede a difundir un mensaje con su uid(i).
• Se elige al primer proceso del cual se recibe un mensaje de difusión.

CORRECTITUD:
• En cada ventana de tiempo de tamaño T, llegará a los más un mensaje de difusión.
• Como los procesos por su identi cador de nen un orden total, el algoritmos terminará antes que transcurra T [s] desde que el
proceso con menor identi cador difundió su mensaje (que es el elegido por todos).

Observación: Nótese existe una única difusión de mensajes para una elección sincrónica.
∴ Complejidad en mensajes del algoritmo: ∼ O(n)
@ Prof. Raúl Monge - 2025 12
fi
fi
fi
fi
fi
 Conclusión sobre el modelo de sincronismo
• El modelo asincrónico es más general, pues no hace supuestos sobre el tiempo.
• El modelo sincrónico es un caso particular de un sistema (asincrónico), que impone ciertas
restricciones temporales para garantizar un determinado comportamiento.
• Conocimiento sobre el tiempo permite, en general, diseñar algoritmos más e cientes (pero podría
ser más complejos de diseñar e implementar).
• Existen problemas que sólo tienen solución en un modelo sincrónico (e.g. consenso con fallas).
• Sincronismo es di ícil de lograr en sistema a gran escala y con redes no ables, pudiéndose en
consecuencia considerarse el modelo asincrónico como un modelo más realista.
• Existe una gradualidad de modelos entre asincrónico estricto y sincrónico total.

Sistema asincrónico Universo de sistema

Sistema sincrónico
@ Prof. Raúl Monge - 2025 13

4.2 Sincronización de relojes

de tiempo real

@ Prof. Raúl Monge - 2025 14

f
 Motivación al uso de relojes
Necesid d de disponer de m rc s de tiempos precis s

APLICACIONES DEL TIEMPO: Disponer de una base de tiempo común es fundamental para resolver problemas de coordinación en
sistemas distribuidos, tales como ordenamiento de eventos, sincronización y consistencia. Por ejemplo:
• Actualización de información (e.g., saber cuál es última versión de un archivo que se actualiza frecuentemente).
• Detección de fallas (e.g., uso de un timer para reconocer que no se responde a tiempo y asumir una falla).
• Causalidad y consistencia (e.g., ordenar mensajes según sus marcas de tiempo, para una interpretación consistente de la
relación causal entre ellos , tal como e-mails en el buzón de entrada).
• Observabilidad y Debugging (e.g., monitorear eventos en un sistema, ordenándolos por tiempo de ocurrencia para analizar
consistentemente la realidad y explicar correctamente un determinado comportamiento observado).

NECESIDADES DE RELOJES Y MARCAS DE TIEMPO:

• Establecer con certeza cuándo sucedieron ciertos eventos en el sistema, para analizar y concluir consistentemente sobre el
comportamiento observado.
• Una marca de tiempo obtenida de la lectura de un reloj (local) permite asociar un tiempo a cada evento de interés.
• Para asociar a los eventos una marca de tiempo con una medición precisa, requiere sincronizar los relojes de los diferentes
procesadores y/o computadores con un alto grado de precisión.
• tb. externamente con un patrón de tiempo universal, si se interactúa con sistemas externos.
@ Prof. Raúl Monge - 2025 15

Modelo de un reloj real o ísico

MODELO DEL SISTEMA: Existen n máquinas (o procesadores) y n relojes en el sistema*. Para cada máquina i, existe
un único proceso Pi que controla el reloj local Ci de esta máquina. ∀i : 1 ≤ i ≤ n, se de ne las siguientes funciones:
• Ci(t) : Lectura de reloj Ci en el tiempo real t
• ci(T ) : Tiempo real cuando el reloj Ci alcanza el valor T (i.e., el tiempo t0 : Ci(t0) = T
* NOTA: Una simpli icación para una arquitectura de computador multicore y/o de múltiples procesadores con memoria compartida.

TIPOS DE RELOJES ( ísicos):

• Reloj perfecto: Si un reloj Ci está siempre perfectamente sincronizado, entonces se cumple:

∀t ≥ 0 : Ci(t) = t
• Reloj correcto: En general, para que cualquier reloj Ci (1 ≤ i ≤ n) esté funcionando correctamente, su tasa de deriva (dri rate) está
acotada a una constante ρ: Es decir:
d
∀t ≥ 0 : C (t) − 1 < ρ
dt i
• Reloj fallado: Un reloj que se detiene o su tasa de deriva excede ρ.

@ Prof. Raúl Monge - 2025 16

a
f
f
a
 Lectura de reloj local
Ejemplo: Time St mp Counter (TSC) de rquitectur X86 en lengu je C
#include <stdio.h> OBSERVACIÓN:
#include <stdint.h>
El programa retorna la cantidad de ciclos
// lectura del tiempo con Asembler X86 usando instrucción de máquina RDTSC
// del registro del TSC (Time Stamp Counter) del procesador asignado del contador TSC transcurridos, en un
static inline uint64_t rdtsc(void) { registro de un número entero de 64b sin
unsigned int lo, hi; signo.
__asm__ volatile ("rdtsc" : "=a" (lo), "=d" (hi));
return ((uint64_t) hi << 32) | lo; // retorna 64 bits de lectura de reloj Si queremos saber el tiempo transcurrido T,
}
se debe calcular:
int main() { end − start [ciclos TSC]
uint64_t start = rdtsc(); T [s] =
// … fTSC [Hz]
// Código que se le quiere medir tiempo de ejecución
// … fTSC está determinado por la frecuencia del
uint64_t end = rdtsc(); reloj del procesador. (e.g., 1.8 [GHz]).
uint64_t cycles = end - start;
printf("Ciclos TSC transcurridos: %llu\n", cycles);
return 0;
}
@ Prof. Raúl Monge - 2025 17

Representación del tiempo en el Computador

• Tiempo en Unix y Posix: medido en intervalos de 1 [s] desde el 1 de enero de 1970. Esta codi cado con un
entero con signo (i.e. 31 bits de magnitud: aprox. 68 años )
• 1.000.000.000 corresponde a 09/Sep/2001, 01 : 46 : 40
• En 2038 habrá cambio de época (problema parecido al año 2.000)
• FILETIME en Windows: medido en intervalos de 100 [ns] desde el 1 de enero de 1601. Representado como
entero sin signo de 64 bits.
• Llamadas al sistema: Analizar las diferencias de:
• time() : reloj del sistema (segundos)
• gettimeofday() : reloj del sistema(microsegundos)
• rdtsc() : Contador de ciclos de CPU (TSC) (nanosegundos)
• clock_gettime() : Timer de alta resolución del sistema (nanosegundos)
@ Prof. Raúl Monge - 2025 18
a
 Deriva de un reloj
Ci(t) (1 + ρ) ⋅ t
Reloj rápido
Ci(t) = t
t0+ Reloj perfecto
t0 (1 − ρ) ⋅ t
t0− Reloj lento

t (tiempo real)
t0
Observaciones:
• ≈ 10−5 (más de 1 [s] de desviación diaria)
Valores típicos de tasa de deriva en relojes de cristal son del orden ρ
• Relojes atómicos pueden tener una tasa de deriva ρ < 10−11 (e.g., menos de 1 [s] de desviación en 6.000 [año]
para uso de Cesio-133).
@ Prof. Raúl Monge - 2025 19

Sincronización de relojes
Problem s y requisitos p r un solución
Problema básico de sincronización de relojes:
• Cada máquina (o procesador) tiene su propio reloj local, siendo la base de tiempo para sus procesos.
• Los relojes se desvían unos de otros (clock skew), si no se hace nada (por inevitable existencia de diferentes tasas de deriva).
• La complejidad de sincronizar relojes es mayor si existen fallas (peor caso: modelo de fallas bizantinas)
Objetivo: Lograr que relojes de diferentes máquinas se coordinen para reducir su desviación del tiempo a un máximo conocido.

Requisitos (propiedades):

• Precisión (precision): Relojes tienen tiempos cercanos entre si. Formalmente, existe una constante de tiempo pequeña π, tal que:
∀i, j : 1 ≤ i, j ≤ n : Ci(t) − Cj(t) < π
• π corresponde en sincronización interna a desviación máximo entre cualquier par de relojes.
• Exactitud (accuracy): Tiempo de cada reloj es cercano al tiempo real. Formalmente, existe una constante de tiempo pequeña α, tal que:
∀i : 1 ≤ i ≤ n : Ci(t) − t < α
• α corresponde en sincronización externa a desviación máxima con un reloj patrón de tiempo real (e.g., UTC: Coordinated Universal Time).
• Monotonicidad. Un reloj siempre se incrementa en el tiempo, i.e.: ∀i : 1 ≤ i ≤ n : t < t′ ⟹ Ci(t) < Ci(t′)
• Ajuste de relojes: consecuencia es no poder tener saltos negativos al sincronizar relojes y se debe reducir velocidad por un lapso de tiempo.

@ Prof. Raúl Monge - 2025 20



a
a
a
 Sincronización de relojes
Cl ses de lgoritmos de sincroniz ción de relojes
• Determinístico:
• Condiciones y límites para la sincronización entre relojes están garantizados (e.g. precisión alcanzable).
• Se requiere limitar retardo máximo de los mensajes (tb. tasa de deriva máxima entre relojes no fallados).
• Ejemplos:
• Algoritmo de Berkeley (1989): Sincronización en una red interna con tolerancia a fallos.
• Algoritmo de Lynch (1988). Sincronización entre relojes, garantizando precisión entre nodos no fallados.

• Probabilístico:
• Condiciones y límites para la sincronización entre relojes están garantizados sólo con cierta probabilidad.
• No se requiere limitar retardo máximo de los mensajes, pero precisión depende de retardos estimados.
• Ejemplos:
• Algoritmo de Cristian (1989): Estima desfase temporal (o set) basado en retardo de la comunicación.
• Protocolo NTP (versión 4: RFC 5905): Uso de ltrado estadístico para acotar el desfase temporal.
Métodos de sincronización: (1) Consultando a un servidor; o (2) cooperativos consultando a un grupo de servidores.
@ Prof. Raúl Monge - 2025 21

Problema estimación en sincronización de relojes

Un cliente PC us un servidor de tiempo PS
• PC sólo puede leer el reloj ísico CS a través de proceso controlador PS, enviándole un mensaje y esperando una
respuesta (e.g. con una invocación remota), lo que toma tiempo.

• PC debe estimar la desviación o desfase temporal (o set) de su reloj CC respecto a CS para luego ajustar su reloj.
• Retardo de comunicación es de tiempo variable, una di cultad para establecer cuándo PS efectivamente leyó su reloj.
• Relojes pueden fallar, dando diferentes lecturas a procesos lectores (i.e. problema de doble cara).

Ts ← readTimeS() Posibles estimaciones en Pc:

T2 TS T3 1. Retardo de comunicación: Δreq ≈ Δrep.
PS
2. Asumir que PS lee en: Ts ≈ (T2 + T3)/2 (según CS).
requestTimeC() replyTimeS() → TS 3. Pc estima en T4 el retardo medio D de la lectura de
PS como: D ≈ (T4 − T1)/2 (según CC).
T1 T4 4. El desfase estimado θCS de reloj CC respecto a CS es:
PC
Δreq Δrep θCS = CC(t) − CS(t) ≈ (T4 + T1)/2 − TS
@ Prof. Raúl Monge - 2025 22
a
a
a
f
 a) Algoritmo de Berkeley (Tempo)
ALGORITMO: Un grupo de n servidores, en un esquema maestro-esclavo (dinámico con elección), se
sincronizan con un coordinador (o líder). Esquema cooperativo, determinístico y tolerante a fallos.
1. Coordinador (maestro) consulta a cada servidor (máquina esclava) el tiempo de su reloj; luego, estima su
o set en base a la demora de su respuesta (round-trip time).
2. Coordinador descarta o set muy desviados, promedia los o sets seleccionados y calcula para cada
servidor su nuevo o set de ajuste (incluido el suyo).
3. Coordinador le envía el o set a cada servidor, para que hagan su ajuste.

CARACTERÍSTICAS:
• Se logra típicamente una precisión del orden de varios milisegundos (sincronización interna), pero el grupo
de servidores sincronizados puede derivar respecto a UTC (i.e. no se considera sincronización externa).
• Permite tolerar fallas de servidor, aislando servidores fallados con excesiva desviación de la mayoría.
• Si fallas no son bizantinas y coordinador no tiene fallas de doble cara, se cumple: 2f + 1 ≤ n

Fuente: R. Gusella & S. Zatti, "The accuracy of the clock synchronization achieved by
TEMPO in Berkeley UNIX 4.3BSD," in IEEE TOSE, 15(7), pp. 847-853, July 1989.
@ Prof. Raúl Monge - 2025 23

Algoritmo de Berkeley
Ejemplo sobre su funcion miento

a) Medidas para b) Cálculo del promedio c) Ajuste de relojes para d) Relojes se encuentran
estimación de o sets del o set, descartando corregir desviación sincronizados
valores fuera de rango según o set promedio

@ Prof. Raúl Monge - 2025 24

ff
ff
ff
ff
ff
ff
ff
a
 Algoritmo de Berkekey
Estim ción del offset
CB(t2)
CONSIDERACIONES. Estimación del o set θAB supone:
PB
• θAB = Ca(t) − CB(t) t2
• Se asume que en corto período: θ(t1) = θ(t3) = θAB = cte .
∴ θAB ≈ 1/2 ⋅ {CA(t1) + CA(t3)} − CB(t2)
t1 t3
PA
ESTIMACIÓN DEL OFFSET: Δreq Δrep
Sea: TRR
CA(t1) CA(t3)
• TRR : round-trip time ; i.e. CA(t3) − CA(t1)
Observaciones:
• Tmin : tiempo mínimo de comunicación para Δreq y Δrep
• Error ϵ depende de tiempos de comunicación TRR.
• ϵ : error estimado para el o set
• Si TRR es muy grande, un timer puede forzar a
Se puede demostrar que error ϵ de estimación de o set θAB repetir la medición.
está acotado a: ϵ ≤ 1/2 ⋅ TRR − Tmin • Error entre par de nodos queda acotado a 2ϵ.
@ Prof. Raúl Monge - 2025 25

b) NTP (Network Time Protocol)

Est nd r RFC 5905 en Internet

• NTP is uno de los protocolos más ampliamente usados para sincronizar relojes en sistemas
distribuidos y es un estándar en Internet.
• Está diseñado para sincronizar los relojes de computadores en una red, asegurando mantener
consistencia y precisión.
• Ofrece tres modos de operación:
• Cliente-Servidor: cliente se sincroniza con uno o más servidores.
• Simétrico: Dos pares de computadores se sincronizan entre ellos; útil para redundancia.
• Broadcast/Multicast: Permite difundir períodicamente información para sincronizar relojes
en una red de área local.
• Algunas características son tolerancia a fallos con replicación de servidores, organización
jerárquica para escalar, autenticación para seguridad, entre otras.
@ Prof. Raúl Monge - 2025 26
á
a
a
ff
ff
 NTP: Modo básico de sincronización
De niciones (Ambas variables se pueden indexar por #ronda): Ti−1
Ti−2
• θ : o set entre los relojes de los servidores PA y PB es:
PB
θ(t) = CB(t) − CA(t) ≈ θ (se asume constante)
• δ : retardo medio de transmisión por mensaje m′ m
(2δ es promedio de tiempo de entrega de un mensaje)

Cálculos intermedios: Entonces podemos calcular:

Ti−3 Ti
•
Ti−2 = (Ti−3 + θ) + Δi−1 y Ti = (Ti−1 − θ) + Δi PA
Δi−1 Δi
•
2δi = Δi + Δi−1 = (Ti − Ti−1) + (Ti−2 − Ti−3)
Variables para ronda #i
Ahora, se estima el tiempo Ti de recepción de mensaje m y se
obtiene o set estimado θi para ronda i: PRECISIÓN:
• Ti = (Ti−1 − θi) + Δi o θi ≈ δi − (Ti − Ti−1) Se demuestra que: θi − δi ≤ θ ≤ θi + δi;
(i.e., el error de medición depende de retardo estimado δi)
Conclusión: Retardo promedio δi y o set θi estimados para ALGORITMO:
ronda #i son:
• Se obtiene 8 pares (θi, δi) sucesivos de estimación (8 rondas)
(T − Tt−3) + (Ti − Tt−1)
δi = i−2
(T − Tt−3) − (Ti − Tt−1)
θi = i−2
• Se elige θi que tiene menor δi como estimación más con able
2 2 para θ.
@ Prof. Raúl Monge - 2025 27

Organización de la Arquitectura NTP

Arquitectur jer rquic de precisión

Estrato: (stratum): NTP utiliza una estructura jerárquica de

servidores de tiempo, organizados en niveles o estratos:
• Stratum 0: Relojes de referencia (e.g., relojes atómicos, GPS)
• < 50 [ns] en GPS
• < 2 [ms] en broadcast RF
• Stratum 1 − 3: Servidores sincronizados directamente con
dispositivos del Estrato 0 o uno de inferior precisión.

Cada estrato aumenta la posibilidad de error de sincronización.

< 1 [ms] en LAN
< 10 [ms] en Internet pública
< 100 [ms] en ASDL pública (asimétrica)

@ Prof. Raúl Monge - 2025 28


fi
ff
ff
a
á
a
ff
 4.3 Causalidad, concurrencia
y Relojes lógicos de Lamport

Fuente: L. Lamport, "Time, clocks, and the ordering of events in a distributed system", Comm. of the ACM 21(7), 1978, pp. 558-565

@ Prof. Raúl Monge - 2025 29

Motivación
• Un sistema distribuido se caracteriza, entre otros, por no tener un base de tiempo
precisa y compartida, lo que desvirtúa el concepto de simultaneidad temporal.
• Muchos problemas se resuelven en base a un razonamiento de lo que pasó antes y
después, para establecer casualidad entre eventos (i.e., ¿cómo un evento pudo haber
in uido en la ocurrencia de otro?).
• Sincronizar relojes reales tiene limitaciones y un costo de coordinación.
• Los relojes lógicos de Lamport tiene en sistemas distribuidos múltiples aplicaciones
por ser un sistema de reloj más liviano. Ejemplos:
• Ordenamiento de eventos y ordenamiento de transacciones
• Seguimiento de causalidad, depuración y monitoreo distribuido
• Exclusión mutua entre procesos, elección de un líder.
@ Prof. Raúl Monge - 2025 30
fl
 Modelo de un sistema distribuido
MODELO: Sea conjunto de n procesos P1, P2, . . . , Pn (secuenciales, concurrentes y asincrónicos), donde:
1. Cada proceso Pi genera localmente una secuencia de eventos Ei, de nida por:
def
∀Pi (1 ≤ i ≤ n) : Ei = {ei,1, ei,2, ei,3, ⋯}
def
El conjunto de todos los eventos del sistema de n procesos, se de ne como: E = {E1, E2, ⋯, En}.
2. La comunicación entre procesos es por paso de mensaje asincrónico, donde los eventos de envío y
recepción usualmente ocurren en diferentes procesos.
◼

ei,p−1 ei,p ei,p+1

Ejemplo: Si un mensaje m es enviado por Pi y
Pi
recibido por Pj, se de ne para ambos eventos:
m
ei,p = sendi(m) y ej,q = recvj(m)
Pj ej,q−1 ej,q+1
ej,q
@ Prof. Raúl Monge - 2025 31

Relación de causalidad →
“H ppen before” (“ocurrió ntes que”)

DEFINICIÓN: Relación “ocurrió antes que” →

La relación → captura la dependencia causal entre dos eventos; i.e., si dos eventos están causalmente
relacionados. Se de ne → por las siguientes tres propiedades:

1) Localidad: ∀a, b ∈ E, a ≠ b : a → b
si eventos a y b son eventos del mismo proceso y a ocurre en este proceso antes que b.

2) Comunicación: ∀a, b ∈ E, a ≠ b : a → b
si a es el evento de envío de un mensaje m en un proceso y b es el evento de recepción de m en otro
proceso.

3) Transitividad: ∀a, b, c ∈ E, eventos diferentes: a → b, b → c ⟹ a → c

@ Prof. Raúl Monge - 2025 32

a
fi
fi
a
 Relación de concurrencia ∥
DEFINICIÓN: Relación de concurrencia ∥.
• Dos eventos distintos a y b son concurrentes (denotado por a ∥ b), si no se afectan
causalmente. Formalmente:
∀a, b ∈ E, a ≠ b : a ∥ b ⟺ ¬(a → b) ∧ ¬(b → a)
◼

Observación: Para l n procesos P1, P2, . . . , Pn, eventos E = {E1, E2, ⋯, En} y la relación de
causalidad →, (E, → ) de ne una computación distribuida.
Dado que eventos concurrentes en E no se pueden ordenar, se dice que → establece sólo un
orden parcial sobre los eventos de E.

@ Prof. Raúl Monge - 2025 33

Ejemplos de causalidad y concurrencia

e1,1 e1,2 e1,3 e1,4

P1 En el ejemplo, se cumple:
m
• e1,1 → e1,3 y e1,2 → e2,3
P2 e2,1 e2,2 e2,3 • e1,2 ∥ e2,1 y e1,4 ∥ e2,2

Comentarios:
• La relación → re eja una potencial in uencia causal, pero que no necesariamente ocurre.

@ Prof. Raúl Monge - 2025 34

fl
fi
fl
 Algunas propiedades de relación →
PROPIEDAD: Concurrencia y causalidad.
• Para dos eventos diferentes a y b cualesquiera, se cumple:
∀a, b ∈ E, a ≠ b : (a → b) ⊻ (b → a) ⊻ (a ∥ b)
PROPIEDAD: Tiempo y relación de causalidad.
• Sea T(e) el tiempo real y absoluto en que sucedió el evento e (medido con un reloj
perfecto). Entonces para dos eventos diferentes a y b cualesquiera se cumple que:
∀a, b ∈ E, a ≠ b : a → b ⟹ T(a) < T(b)

Observación: Si T(a) < T(b), no es posible a rmar que a y b estén causalmente conectados.

@ Prof. Raúl Monge - 2025 35

Relojes Lógicos de Lamport

Suposiciones inici les

• Se asume independencia entre relojes ísicos y relojes lógicos.

• En cada proceso Pi del sistema existe un único reloj lógico LCi (escalar en ℕ0).

• Cada evento a que ocurre en el sistema recibe un tiempo lógico LC(a), denominada
también “marca de tiempo” (timestamp).

• LC() puede ser vista como una función que asigna en un proceso a cada evento
local a una marca de tiempo LC(a).

@ Prof. Raúl Monge - 2025 36

a
 Relojes Lógicos de Lamport
Condiciones de Reloj

Las marcas de tiempo de los relojes lógicos para los eventos pueden ser
implementados, si se cumplen las siguientes dos condiciones:

[C1]: Para dos eventos a y b pertenecientes al proceso Pi :

Si a → b, entonces LC(a) < LC(b)

[C2]: Si a es el evento de envío de un mensaje m en el proceso Pi

y b es el evento de recepción del mismo mensaje m en el proceso Pj,
entonces LCi(a) < LCj(b)

@ Prof. Raúl Monge - 2025 37

Reglas de implementación
[IR1]: Eventos locales
• El reloj LCi es incrementado para dos eventos locales sucesivos en el proceso Pi, según:
LCi ← ′LCi + d (con d > 0)
• Si a y b son dos eventos sucesivos en el proceso Pi y a → b, entonces se cumple:
LCi(b) = LCi(a) + d

[IR2]: Eventos de comunicación

• Si a es el evento de envío de un mensaje m en el proceso Pi, entonces m obtiene como marca de tiempo:
LC(m) ← LCi(a)
• Al recibirse el mismo mensaje m en el proceso Pj, su reloj LCj es incrementado a:
LCj ← max{′LCj, LC(m)} + d (con d > 0)

• Y si b es el evento de recibo del mensaje m en Pj, entonces se cumple:

LCj(b) = LCj (usando valor actualizado del reloj lógico).
@ Prof. Raúl Monge - 2025 38


 Ejemplo: marcado de eventos

INICIALMENTE:
e1,1 e1,2 e1,3 e1,4 e1,5 e1,6 e1,7
LC1 = 0 P1 m1 (4) m4
(1) (2) (3) (5) (6) (7)

(1) (2) m2 (3) (4) m3 (7)

LC2 = 0 P2 e2,1 e2,2 e2,3 e2,5
e2,4

Se asume siempre que incremento: d = 1

@ Prof. Raúl Monge - 2025 39

Ordenamiento total de eventos

Aplic ción de Relojes Lógicos de L mport

Objetivo:
• Encontrar un orden total sobre los eventos de un sistema E, para resolver
problemas de decisión con control distribuido.
• Todos los procesos observan el mismo orden para todos los eventos de E.

Aplicaciones:
• Ordenar mensajes, respetando causalidad
• Transacciones distribuidas
• Observación o monitoreo de un sistema

@ Prof. Raúl Monge - 2025 40

a
 Relación de orden total ≺
DEFINICIÓN: Relación de orden total ≺. Se asume existencia de orden total para procesos y sean a
un evento en Pi y b un evento en Pj. Entonces, ∀a ∈ Ei, b ∈ Ej, a ≠ b, se de ne a ≺ b por dos reglas:
(i) LCi(a) < LCj(b) , o
(ii) LCi(a) = LCj(b) y Pi < Pj
◼
Observaciones:
Ejemplo:
e1,1 e1,2 e1,3 e1,4 e1,5 e1,6 e1,7 • Si a → b ⟹ a ≺ b
P1 m1 (4) (6) m4 • Eventos concurrentes se ordenan
(1) (2) (3) (5) (7)
"arbitrariamente", pero en forma única.

P2
(1) (2) m2 (3) (4) m3 (7) • Cualquier observador aplicando ≺
e2,1 e2,2 e2,3 e2,4 e2,5 generará el mismo orden para (E, → ).
Si P1 < P2, entonces los eventos se ordenan así: < e1,1, e2,1, e1,2, e2,2, e1,3, e2,3, e1,4, e2,4, e1,5, e1,6, e1,7, e2,5 >
@ Prof. Raúl Monge - 2025 41

Limitaciones de Relojes Lógicos de Lamport

Problemas:
1. No es posible determinar causalidad o concurrencia entre dos eventos cualesquiera si
sólo se conocen las marcas de tiempo de un Relojes Lógico de Lamport.
2. Existe falta de densidad (no es posible saber a partir de las marcas de dos eventos si
existe o no otro evento con una marca intermedia, especialmente si d > 1).
Observaciones:
• Relojes reales sufren también de ambos problemas.
• Además, relojes reales sólo garantizan ordenamiento total (respetando causalidad), si
existe sincronismo perfecto (una imposibilidad).
• La diferencia sustancial radica en que el valor de un reloj lógico en principio no tiene
relación con el tiempo real y no es una métrica de tiempo.
@ Prof. Raúl Monge - 2025 42
 4.4 Relojes vectoriales

Fuente: O. Babaglou, K. Marzullo, "Consistent Global States of Distributed Systems: Fundamental Concepts and Mechanisms". Technical Report UBLCS-93-1. January 1993. Laboratory for Computer Science.
University of Bologna. Bologna (Italy).

@ Prof. Raúl Monge - 2025 43

Motivación a relojes vectoriales

Ejemplos plic ción

• Monitoreo y depuración distribuidas (e.g. causalidad de eventos, análisis de

concurrencia y cuellos de botella)
• Control de consistencia de réplicas (e.g. sistemas de archivos, bases de datos)
• Control de versiones (e.g. Git, edición colaborativa de documentos, copias en
cache)
• Orden causal de mensajes o eventos (e.g. sistemas de mensajería, consenso
distribuido)
• Juegos multi-jugador en línea (sincronizar eventos o acciones de jugadores entre
servidores)

@ Prof. Raúl Monge - 2025 44

a
a
 Historia causal
DEFINICIÓN: Historia causal de un evento. En una computación distribuida (E, → ), la
historia causal de un evento e ∈ E —denotado como h(e)—, se de ne como:
def
h(e) = {e′ ∈ E | e′ → e} ∪ {e}
◼

e1,1 e1,2 e1,3 e1,4 e1,5 e1,6 e1,7

P1
PREGUNTA: m1 m4
m2 m3
¿Cuál es la historia causal h(e1,6)?
P2 e2,1 e2,2 e2,3 e2,5
e2,4

RESPUESTA: h(e1,6) = {e1,1, e1,2, e1,3, e1,4, e1,5, e1,6, e2,1, e2,2}

Fuente: Schwarz, R. & Mattern, F., "Detecting Causal Relationships in Distributed Computations: In Search of the Holy Grail", Distributed Computing, Springer Verlag, 1994.
@ Prof. Raúl Monge - 2025 45

Historias causales
Propied des

Propiedad Nº1: ∀e, e′ ∈ E, e ≠ e′ : [e′ → e] ⟺ [h(e′) ⊂ h(e)]

Propiedad Nº2: ∀e, e′ ∈ E, e ≠ e′ : [e′ ∥ e] ⟺ [h(e′) ⊄ h(e)] ∧ [h(e′) ⊄ h(e)]

COMENTARIOS:
• Las historias causales permiten detectar si existe concurrencia o causalidad entre 2 eventos.
• Una condición de reloj más fuerte es posible realizarla considerando las dos propiedades
anteriores, cuya implementación denominaremos “relojes vectoriales”.
• Los relojes vectoriales fueron propuestos "concurrentemente" por Fidge y Mattern, en 1988.
Fuentes primarias:
• C. J. Fidge. Timestamps in message-passing systems that preserve the partial ordering. In Eleventh Australian Computer Science Conference, pp. 55–66, U. of Queensland, February 1988.
• F. Mattern. Virtual time and global states of distributed systems. In Proc. of the International Workshop on Parallel and Distributed Algorithms, pp. 215–226. North-Holland, October 1989.
@ Prof. Raúl Monge - 2025 46








a
 Proyecciones de una historia causal
DEFINICIÓN: Proyección de una historia causal. Para un evento e ∈ E, la proyección de h(e)
def
sobre Ei, denotada por hi(e), se de ne como: hi(e) = h(e) ∩ Ei

Observaciones:
n n

⋃ ⋂
1. Todos las proyecciones de h(e) de nen una partición; i.e.: hi(e) = h(e) y hi(e) = ϕ
i=1 i=1
2. Para la historia causal de un evento e vale: ∀ei,k ∈ Ei : {ei,k ∈ hi(e) ⟺ ∀j, j < k : ei,j ∈ hi(e)}
∴ Basta un número entero único para representar hi(e), el último evento por proceso.

Ejemplo: usando la gura del ejemplo anterior.

• Se tiene dos proyecciones: h1(e1,6) = {e1,1, e1,2, e1,3, e1,4, e1,5, e1,6}, h2(e1,6) = {e2,1, e2,2}

• h1(e1,6) ∪ h2(e1,6) = h(e1,6) y h1(e1,6) ∩ h2(e1,6) = ϕ

@ Prof. Raúl Monge - 2025 47

Reloj vectorial (tb. Vector de tiempo)

De inición

DEFINICIÓN: Reloj vectorial (VC). Sean n procesos; VC es un vector n-dimensional

que a un evento e le asigna una marca VC(e) que representa a h(e), tal que:
∀i,1 ≤ i ≤ n : VC(e)[i] = k ⟹ ei,k ∈ hi(e) ∧ ei,k+1 ∉ hi(e)
Se dice que “VC(e) es la marca del reloj vectorial para el evento e”

◼
OBSERVACIÓN:
• ∀e ∈ E : VC(e) representa exactamente h(e).
• Considerando propiedades anteriores 1 y 2, es posible determinar con los relojes vectoriales
si existe causalidad o concurrencia entre un par de eventos cualesquiera.
@ Prof. Raúl Monge - 2025 48
f
fi
fi
fi
 Reloj vectorial
Modelo de implement ción

• Como en relojes lógicos de Lamport, cada proceso Pi del sistema puede mantener
un reloj local VCi que re eje el conocimiento global que tiene el este proceso sobre
los eventos ocurridos en el sistema.
∴ Existirán n relojes vectoriales en el sistema (uno por proceso),
donde cada vector tendrá n dimensiones (conocimiento sobre cada proceso).

• A cada evento local y de envío de un mensaje de un proceso Pi, se le puede asociar

una marca de tiempo igual al valor que tiene el reloj vectorial local VCi .

• Inicialmente: ∀i, j : 1 ≤ i, j ≤ n : VCi[ j] = 0

@ Prof. Raúl Monge - 2025 49

Reloj vectorial
Interpret ción oper cion l

• Cada proceso Pi asignará una marca de tiempo a cada uno de sus eventos locales o
de comunicación e, tal que:

• ∀i : 1 ≤ i ≤ n : VCi(e)[i] :
Nº de eventos que han ocurrido en Pi cuando sucede evento e

• ∀i, j : 1 ≤ i, j ≤ n, i ≠ j : VCi(e)[ j] :
Nº de eventos que Pi conoce de Pj cuando sucede e

@ Prof. Raúl Monge - 2025 50

a
a
a
fl
a
 Reloj vectorial
Regl s de implement ción
[IR1]: Evento local. Si ei,k es un evento interno o de envío en el proceso Pi, entonces:
1. VCi(ei,k)[i] ← VCi(ei,k−1)[i] + 1
2. ∀j, i ≠ j : VCi(ei,k)[i] ← VCi(ei,k−1)[i]
En caso de ser ei,k evento de envío de mensaje m, entonces m llevará una marca de reloj VC(m) igual a la marca del
evento de envío (local); i.e. VC(m) = VCi(ei,k).

[IR2]: Evento de comunicación. Si en el proceso Pi el evento ei,k es un evento de recepción de un mensaje m con
marca de tiempoVC(m), entonces:
i) VCi(ei,k)[i] ← max{VCi(ei,k−1), VC(m)}
• {ii) VCi(ei,k)[i] ← VCi(ei,k)[i] + 1
VCi(ei,k) :=

OBSERVACIÓN:
• Se ha tratado la recepción de un mensaje como un evento local más del proceso receptor Pi.
• Valor del reloj para otro proceso debe ser igual a marca del último evento conocido por el proceso receptor.
@ Prof. Raúl Monge - 2025 51

Ejemplo: Relojes vectoriales

M rc do de eventos con relojes vectori les

Inicialmente:

VC1 = (0,0,0) (1,0,0) (2,0,0) (3,0,0) (4,0,0) (5,5,3)

P1 e1,1 e1,2 e1,3 e1,4 e1,5
m1 m4
(0,1,0) (0,2,0) (2,3,0) (2,4,3) (2,5,3) (2,6,3)
VC2 = (0,0,0)
P2 e2,1 e2,2 e2,3 e2,4 e2,5 e2,6
m2 m3

P3
VC3 = (0,0,0) (0,0,1) (0,2,2) (0,2,3) (0,2,4) (0,2,5)

e3,1 e3,2 e3,3 e3,4 e3,5

@ Prof. Raúl Monge - 2025 52

a
a
a
a
 Condición fuerte de reloj
Rel ción de orden de m rc s de relojes vectori les

DEFINICIÓN: Relación de igualdad y de orden para relojes vectoriales.

a) V = V ′ ≡ { ∀k : V[k] = V ′[k]}
b) V < V ′ ≡ {V ≠ V ′} ∧ { ∀k : V[k] ≤ V ′[k]}
◼
Nótese que ¬(V < V ′) no es equivalente a decir: (V ′ < V) ∨ (V ′ = V)

PROPIEDAD: Condición fuerte de reloj.

a) e → e′ ≡ VC(e) < VC(e′)
b) e ∥ e′ ≡ ¬{VC(e) < VC(e′)} ∧ ¬{VC(e′) < VC(e)}
◼
@ Prof. Raúl Monge - 2025 53

Propiedades de Relojes Vectoriales

PROPIEDAD: Número de eventos precedentes. Sean ei ∈ Ei y marca vectorial del evento VC(ei).
Entonces el el número total de eventos e′ que preceden a ei (i.e., cumplen que e′ → ei ), está dado
por:
n

( ∑ VC(ei)[ j] )− 1
j

PROPIEDAD: Detección de apertura. Sean ei ∈ Ei y ej ∈ Ej dos eventos conocidas con i ≠ j

(i.e., ambos eventos suceden en diferentes procesos). Entonces:
VC(ei)[i] < VC(ej)[i] ⟹ ∃e′ ∈ Ei : ei → e′ → ej

OBSERVACIÓN: Esta última propiedad permite a un proceso Pj detectar que existe un evento e′ que
ocurre en otro proceso Pi después que un evento ei ya conocido por Pj.

@ Prof. Raúl Monge - 2025 54
















a
a
a
 Evaluación de Relojes vectoriales
Capacidades:
• Detección de causalidad: Permite establecer dependencia causal entre eventos.
• Detección de concurrencia: Permite establecer que eventos no tienen relación causal.
• Coordinación centralizada: Un mecanismo de marcas de tiempo en sistemas (relativamente ) centralizados.
• Tolerancia a fallos: Al ser descentralizado, funciona bien en sistemas sin un único punto de falla.

Limitaciones:
• Overhead: Tamaño de vectores consumen memoria y ancho de banda; por lo mismo, no escala bien para
grandes sistemas (con aumento de Nº de procesos).
• Complejidad: Operaciones son más complejas que marcas escalares, tal como en relojes de tiempo real y
relojes lógicos de Lamport.
• Sistemas dinámicos. Es di ícil manejar los vectores si proceso entran o salen del sistema, requiriendo
redimensionar su tamaño.
• Modelo de fallas. No tolera fallos bizantinos.

@ Prof. Raúl Monge - 2025 55

Caso: Monitoreo de una

computación distribuida y
observaciones válidas

@ Prof. Raúl Monge - 2025 56

f
 Monitoreo de una computación distribuida
Concepto de observ ción v lid

OBSERVACIÓN: Una observación de una Computación

computación distribuida(E, → ), en general, impone Monitor distribuida
un cierto orden arbitrario a los eventos, que no
P0 P1 P2 Pi Pn
necesariamente respeta el orden parcial establecido
por la relación →. Denotaremos por ei ≺ ej para
expresar que “ei se observa antes que ej”.

DEFINICIÓN: Observación válida. Para que una

observación sea válida sobre (E, → ), debe cumplirse que
se respete en toda observación el orden parcial de los
eventos sobre. Es decir :
∀ei, ej ∈ E, i ≠ j : ei → ej ⟹ ei ≺ ej
∴ no se impone orden a eventos concurrentes.
@ Prof. Raúl Monge - 2025 57

Modelo de implementación
• Todos los procesos Pi (1 ≤ i ≤ n) de (E, → ) envían mensajes a un monitor P0,
noti cándole sobre los eventos observables (de interés para monitorear).
• Cada mensaje m enviado por un proceso Pi al monitor Po lleva una marca VCi(m).
• P0 mantiene una cola de mensajes Q, conjunto de mensajes recibidos y no entregados.
• Cola Q está inicialmente vacía.

Sistema de Monitor
P1
Computación Q
P2
distribuida P0
(E, → ) Cola de Proceso
mensajes monitor
Pn

@ Prof. Raúl Monge - 2025 58

fi
a
á
 Condiciones de entrega causal
Concepto de recepción y orden miento en entreg de mens jes

CONCEPTO: Sea send(m) ∈ Ej (mensaje m enviado desde proceso Pj) y m ∈ Q.

Entonces, para asegurar Observación válida es seguro entregar m en monitor P0, ssi:
∄m′ : (m′ ∈ Q) ∨ (m′en tránsito en la red) : send(m′) → send(m)

Para cumplir lo anterior, es su ciente veri car antes de entregar m a P0 que se

cumplan dos condiciones:
1. Condición FIFO (para mensajes enviados por un mismo proceso Pj)
2. Condición causal (mensajes enviados desde cualquier otro proceso Pk, k ≠ j)

@ Prof. Raúl Monge - 2025 59

Condiciones de entrega causal

Form liz ción de l s condiciones neces ri s y su icientes

Para la entrega correcta (i.e., en orden causal) en Po del mensaje m ∈ Q proveniente de Pj (i.e.,
sendj(m) ∈ Ej), se deben cumplir dos condiciones:
1. Condición FIFO (mismo proceso origen):
∄m′ ∈ Ej : {sendj(m′) → sendj(m)} ∧ {(m′ no ha sido entregado en P0}

2. Condición causal (diferentes procesos de origen):

Si m′ es último mensaje entregado de Pk en Po (i.e. sendk(m′) ∈ Ej y m′ entregado), con k ≠ j,
entonces para entregar m de Pj en P0, se debe cumplir para procesos diferentes a Pj:

∀k, k ≠ j : ∄m′′, sendk(m′′) ∈ Ek :

{sendk(m′) → sendk(m′′) → sendj(m)} ∧ {(m′′ no ha sido entregado en P0}
@ Prof. Raúl Monge - 2025 60















a
a
a
fi
 Veri icación de condiciones de entrega
Aplic ndo relojes vectori les p r entreg r m proveniente de Pj

Condición FIFO: Fácil de veri car con relojes vectoriales, pues se debe cumplir que:
VC(m)[ j] − 1 : mensajes han sido entregados en P0 para Pj

Condición de entrega causal: Se realiza aplicando Propiedad de Detección de Apertura (PDA),

haciendo i = k y considerando los siguientes eventos:
ei = sendk(m′), e′ = sendk(m′′) y ej = sendj(m)
Y dado que ei, e′ ∈ Ek (eventos de proceso Pk diferente a Pj), PDA se puede reescribir como:
∃k, k ≠ j : {VC(m′)[k] < VC(m)[k]} ⟹ ∃m′′, sendk(m′′) ∈ Ek : {sendk(m′) → sendk(m′′) → sendj(m)}

Luego, para que no exista mensaje m′′, se debe negar la expresión anterior, quedando:
∀k, k ≠ j : {VC(m′)[k] ≥ VC(m)[k]}
@ Prof. Raúl Monge - 2025 61

Algoritmo de entrega causal (1/2)

Est do de entreg de mens jes en el Monitor (P0)

DEFINICIÓN: Contador de entrega de mensajes. Usar en monitor P0 un vector n-dimensional

D, que representa a n contadores de mensajes entregados para cada proceso Pj (1 ≤ j ≤ n).
Es decir:
D[ j] : número de mensajes entregados para proceso Pj
◼
Inicialmente:
D←0 (i.e., ∀i,1 ≤ i ≤ n . : D[i] ← 0; no se ha entregado ningún mensaje)

Entrega de un mensaje: Si último mensaje entregado para proceso Pj es el mensaje m, entonces:

D[ j] = VC(m)[ j]
@ Prof. Raúl Monge - 2025 62













a
a
f
a
a
fi
a
 Algoritmo de entrega causal (2/2)
Regl s de entreg de mens jes

Regla Nº1: Entregar en monitor Po mensaje m desde Pj tan pronto se cumplan las
siguientes dos condiciones:

1. D[ j] = VC(m)[ j] − 1 (condición FIFO)

2. ∀k, k ≠ j : D[k] ≥ VC(m)[k] (condición causal)

Regla Nº2: Si se ha cumplido regla anterior y se ha entrega en Po mensaje m

proveniente de proceso Pj, entonces actualizar contador de entrega D:

• D[ j] ← VC(m)[ j] (Contador de entrega de mensajes de Pj)

@ Prof. Raúl Monge - 2025 63

Ejemplo de Monitor con Entrega causal

Gener ción de un observ ción v lid

P0 D = (0,0,0) (1,0,0)(1,1,0) (1,1,1) (1,2,1) (1,3,1) (1,4,1)(2,4,1)(2,4,2)

(1,0,0)
P1 e1,1
(2,4,1)
e1,2

P2 (1,1,0) (1,2,1) (1,3,1)

e2,2 e2,3
(1,4,1)
e2,4
e2,1
(0,0,1)
P3 e3,1 e3,2
(1,3,2)

@ Prof. Raúl Monge - 2025 64

a
a
a
a
a
a
 4.5 Estados globales y
consistencia

@ Prof. Raúl Monge - 2025 65

Estado Global y Corte

MODELO: Sea un conjunto de procesos P1, P2, ⋯, Pn secuenciales y concurrentes, que representan una computación
distribuida (E, → ). Entonces se de ne:

DEFINICIÓN: Corte. Un corte C de una computación distribuida (E, → ) es un subconjunto nito de eventos de E, tal
que:
∀e, e′ : (e, e′ ∈ Ei) ∧ (e ∈ C) ∧ (e′ → e) ⟹ e′ ∈ C
◼

DEFINICIÓN: Estado global. El estado global S = {s1, s2, s3, ⋯, sn} asociado al corte C es un conjunto de estados
locales (uno por proceso), tal que para cada evento ei ∈ C :
El efecto del evento ei está re ejado en el estado si de (E, → ).
◼

66

@ Prof. Raúl Monge - 2025




fl
fi
 Ejemplo de Estados globales
C1 C2 C3

P1 e1,1
s1,1 s1,2 s1,3

e1,5
e1,2 e1,3 e1,4
P2 s2,1 s2,2

e2,2 e2,3
s2,3

e2,4 e2,5 e2,6

e2,1
P3 s3,1 s3,2 s3,3

e3,1 e3,2 e3,3 e3,4 e3,5

C1 = {e1,1, e2,1, e3,1} S1 = {s1,1, s2,1, s3,1}

C2 = {e1,1, e1,2, e2,1, e3,1, e3,2} S2 = {s1,2, s2,2, s3,2}

C3 = {e1,1, e1,2, e1,3, e1,4, e2,1, e2,2, e2,3, , e3,1, e3,2, e3,3} S3 = {s1,3, s2,3, s3,3}
@ Prof. Raúl Monge - 2025 67

Estados globales consistentes

DEFINICIÓN: Corte consistente. Un corte C, tal que C ⊆ E de una computación distribuida
(E, → ), es consistente ssi:
∀e, e′ ∈ E : (e ∈ C) ∧ (e′ → e) ⟹ e′ ∈ C
◼

DEFINICIÓN: Estado global consistente. Un estado global S es consistente, ssi S está asociado a
un corte consistente.
◼

Interpretación operacional de consistencia: Un estado global S = {s1, s2, s3, ⋯, sn} para n procesos es
consistente, ssi para cada par de procesos Pi y Pj (i ≠ j) se cumple que:

• ∄ mensaje m enviado por Pi después de tomar su estado si y recibido por Pj antes de tomar su estado sj
@ Prof. Raúl Monge - 2025 68


 Ejemplo de consistencia
C1 C2 C3

P1 e1,1
s1,1 s1,2 s1,3

e1,5
e1,2 e1,3 e1,4
P2 s2,1 s2,2

e2,2 e2,3
s2,3

e2,4 e2,5 e2,6

e2,1
P3 s3,1 s2,3 s3,3

e3,1 e3,2 e3,3 e3,4 e3,5

¡C1 y C2 son consistentes!

¡C3 no es consistente!
@ Prof. Raúl Monge - 2025 69

Algoritmo de Chandy-Lamport (1/2)

Objetivo: Registrar un estado global consistente de una computación distribuida*, sin detener la
ejecución de la computación en curso.
* modelo asincrónico y sin fallas

Suposiciones:
• Procesos se comunican por paso de mensajes unidireccional, usando canales FIFO.
• Topología conocida, que corresponde a un Grafo Dirigido Conectado.
• Alguien comienza el algoritmo (e.g. un proceso controlador o iniciador).
• Cada uno de los procesos es capaz de registrar su estado local.
• Cada proceso es capaz de registrar el estado de todos sus canales de entrada.
• Una vez terminado el algoritmo, el estado de todos los procesos y canales puede ser recolectado
para obtener el estado global del sistema (e.g. por el controlador).

Fuente: Chandy, K. M., & Lamport, L., “Distributed snapshots: Determining global states of distributed systems”. ACM Transactions on Computer Systems, 3(1), pp. 63-75, Feb. 1985.
@ Prof. Raúl Monge - 2025 70
 Algoritmo de Chandy-Lamport (2/2)
• Partida: Inicialmente un único proceso cualquiera recibe una marca (e.g. de un proceso controlador o autoenvío).

• Ejecución: Cada proceso Pi que recibe una marca de partida o desde un proceso cualquiera Pj, por medio algún
canal de entrada denotado como Cj→i, ejecuta el siguiente algoritmo:

if (Pi recibe por primera vez una marca) then { /* realiza atómicamente */
· Pi registra su estado local si;
· Pi registra el estado de todos sus canales de entrada como vacíos;
· Pi envía una marca a todos sus vecinos (usando sus canales de salida);

} else { /* Pi recibe otra vez una marca; en este caso, por canal de entrada Cj→i */
· Pi registra el canal de entrada Cj→i igual a secuencia de mensaje
recibidos por este canal desde que Pi registró su estado si;
}

@ Prof. Raúl Monge - 2025 71

Demostración (1/2)
) Algoritmo registr un est do consistente

Demostración por el absurdo: Suponga que algoritmo registra un estado inconsistente.

Entonces existe un par de procesos Pi, Pj y un mensaje m, tal que se dé el siguiente escenario:

si
Pi
m En el corte de este estado global se observa que
sj Pj ha recibido m, sin embargo m no ha sido
Pj
enviado por proceso Pi .
¿Envío de marca?

Contradicción: Este escenario no es posible, pues el algoritmo exige enviar

inmediatamente la marca a sus vecinos cuando registra su estado local y como los
canales son FIFO, Pj debe haber tomado su estado sj antes de la llegada de mensaje m.
@ Prof. Raúl Monge - 2025 72
a
a
a
 Demostración (2/2)
b) Algoritmo registr correct mente est do de los c n les

Demostración por inducción: Suponga un par de procesos Pi y Pj donde existe un canal

< Pi, Pj > . Entonces, cuando Pi registra su estado local si, debe enviar una marca a Pj.
si
Pi
m1 m2 m3 m4
sj
Pj

Argumentación: ¡Envío de marca!

• Cuando Pj registró su estado local sj, también registró como vacío su canal de entrada Ci,j.

• Cuando Pj recibe la marca por canal de entrada Ci,j, ha registrado los mensajes {m2, m3} como el
estado de este canal: los dos mensajes en tránsito asociado al corte.
∴ Existencia de canales FIFO asegura Pj haya registrado exactamente los mensajes en tránsito (Q.E.D.)
@ Prof. Raúl Monge - 2025 73

Ejemplo de ejecución de Algoritmo de Ch-L (1/2)

Registro de est do glob l P1 P3

Algoritmo parte en P3
P2 P4

P1

P2

P3

P4

@ Prof. Raúl Monge - 2025 74

a
a
a
a
 Ejemplo de ejecución de Algoritmo de Ch-L (2/2)
An lisis del corte P1 P3 *

P2 P4

P1

P2

P3

P4

@ Prof. Raúl Monge - 2025 75

Visión de una computación distribuida

Secuenci de c mbios de est dos glob les

S1 S2 S3 S4 S5 S6 S7 S8 S9

P1 e1,1 e1,5
e1,2 e1,3 e1,4
P2 e2,2 e2,3 e2,4 e2,5 e2,6
e2,1
P3
e3,1 e3,2 e3,3 e3,4 e3,5

Notación: Los cambios de estados se denotan como:

S1 ↝ S2 ↝ S3 ↝ S4 ↝ S5 ↝ S6 ↝ S7 ↝ S8 ↝ S9
*
Y se dice que S9 es alcanzable desde S1, denotado por: S1 ↝ S9
@ Prof. Raúl Monge - 2025 76
á
a
a
a
 Estados estables
DEFINICIÓN: Estado estable. Un sistema está en un estado estable si existe una
*
propiedad estable , tal que: ∀S, S′ : (S) ∧ (S ↝ S′) ⟹ (S′)
◼
St1 S* St2
Ejemplos de estados estables:
P1
• El sistema está en deadlock.
• El algoritmo terminó. P2
• Al menos 20 mensajes han sido enviados.
P3
* *
En la gura se cumple: St1 ↝ S* ↝ St2. Luego:
(S*) ⟹ (St2) y ¬ (S*) ⟹ ¬ (St1)
@ Prof. Raúl Monge - 2025 77

4.6 Conclusiones

@ Prof. Raúl Monge - 2025 78

𝒫
𝒫
𝒫
𝒫
𝒫
𝒫


fi
 Lecciones principales
1. Se revisaron diferentes tipos de coordinación en sistemas distribuidos, el concepto de
tiempo y uso de relojes para marcar eventos en una computación distribuida.
2. Se han estudiado los límites de los algoritmos de sincronización de relojes reales en
cuanto a precisión y exactitud, eventualmente en escenarios de fallas.
3. Se ha formalizado el concepto de dependencia causal y concurrencia para establecer
un ordenamiento parcial de los eventos de un sistema.
4. Se han estudiado dos sistema de relojes lógicos para sistemas asincrónicos: Relojes de
Lamport y relojes vectoriales; se vieron algunas de sus aplicaciones.
5. Se ha formalizado el concepto de un estado global consistente y se ha visto el
algoritmo de Chandy-Lamport para obtener una instantánea distribuida y consistente.

@ Prof. Raúl Monge - 2025 79

Material de estudio complementario

TEXTOS GUÍAS:
• Van Steen, et al. (2023). Cap. 5, secciones 5.1 y 5.2, pp. 247-271.
• Coulouris, et al. (2012). Cap. 14, secciones 14.1-14.5, pp. 595-619.
LECTURAS COMPLEMENTARIAS:
• L. Lamport, "Time, clocks, and the ordering of events in a distributed system", Comm. of the ACM, 21(7), pp.
558-565, 1978.
• M. Chandy and L. Lamport. "Distributed Snapshots: Determining Global States of Distributed Systems". ACM
Transactions on Computing Systems, 3(1) pp. 63-75, Feb. 1985.
• O. Babaglou, K. Marzullo, "Consistent Global States of Distributed Systems: Fundamental Concepts and
Mechanisms". Technical Report UBLCS-93-1. January 1993. Laboratory for Computer Science. University of
Bologna. Bologna (Italy).
• Schwarz, R. & Mattern, F., "Detecting Causal Relationships in Distributed Computations: In Search of the Holy
Grail", in Distributed Computing, Springer Verlag, 1994.

@ Prof. Raúl Monge - 2025 80

 Capítulo IV:
Fundamentos teóricos de
computación distribuida
Sincronismo, relojes, c us lid d y consistenci de est dos glob les

Prof. Dr.-Ing. R úl Monge Anw ndter ⧫ 1er semestre 2025

@ Prof. Raúl Monge - 2025
a
a
a