1/21

SynchronizationLamport Logical Clock and Clock Vectors

Pedro F. Souto (pfs@fe.up.pt)

May 5, 2021

2/21

Roadmap

The Happened-Before Relation

Lamport Clocks and Timestamps

Vector Clocks and Timestamps

3/21

Roadmap

The Happened-Before Relation

Lamport Clocks and Timestamps

Vector Clocks and Timestamps

4/21

Events

I Often, there is no need for synchronized clocksI Sometimes, we just need to order events

Event is an action that takes place in the execution of an algorithm

Sending of a messageDelivery of a messageComputation step

Execution of a distributed algorithm by process i can be definedas a sequence of events:

e0i e1

i e2i . . .

I Each event in an execution is an instance of a given eventtype

5/21

The Happened-Before Relation (→)

HB1 If e and e′ are events that happen in that order in the sameprocess, then e→ e′

HB2 If e is the sending of a message m and e′ is the reception of thatmessage, then e→ e′

HB3 If e→ e′ and e′ → e′′, then e→ e′′

I That is, the HB relation is transitive

m1

e

a b

c d

f

p2

p1

m2

p3

I The HB relation is a partial order. For example:a 6→ e ∧ e 6→ a

I Events like a and e are concurrent: a ||eI The HB relation captures the potential causality between events

6/21

Roadmap

The Happened-Before Relation

Lamport Clocks and Timestamps

Vector Clocks and Timestamps

7/21

Lamport Clocks and Timestamps

Lamport clock is a logical clock used to assign (Lamport) timestampsto eventsI Each process in the system has its own Lamport clock Li

(Lamport) clock condition For any events e and e′:

e→ e′ ⇒ L(e) < L(e′)Or equivalently:

L(e) ≥ L(e′)⇒ e 6→ e′

8/21

Satisfying the Clock Condition

C1 If e and e′ are events in process pi and occur in that order,then Li(e) < Li(e′)

C2 Ife is the sending of a message by process pi , ande′ is the receipt of that message by a process pj

then Li(e) < Lj(e′)

9/21

(Physical Clocks vs. Lamport Clocks)

0 6

12 18 24 30 36 42 48 54 60

0 8

16 24 32 40 48 56 64 72 80

0 10 20 30 40 50 60 70 80 90 100

m1

m2

m3

m4

0 6 12 18 24 30 36 42 48 70 76

0 8 16 24 32 40 48 61 69 77 85

0 10 20 30 40 50 60 70 80 90

100

m1

m2

m3

m4

P adjusts its clock

P adjusts its clock

(b)(a)

P1 P2 P3 P1 P2 P3

2

1

I Free-running physical clocks cannot be used as Lamport clocksI If the clock resolution is small enough C1 is easy to ensureI The problem is with C2

10/21

Lamport Clocks and Timestamps (2/3)

I The timestamp of an event at process i is assigned by Li , theLamport clock at the process i

Lamport Clock Update Rules To satisfy the Clock Condition aLamport clock must be updated before assigning its value to theevent as follows:LC1 if e is not the receiving of a message, just increment LiLC2 if e is the receiving of a message m:

Li = max(Li ,TS(m)) + 1where TS(m) is the timestamp of the corresponding sendingeventI Implementing LC2 requires piggybacking the timestamp of the

sending event on every message

IMP. Incrementing a Lamport clock is not an event

11/21

Lamport Clocks and Timestamps (3/3)

m1

e

a b

c d

f

p2

p1

m2

p3

2

3 4

1

1 5

I If we need to order all events we can use the pair (extendedLamport timestamp):

(L(e), i)where i is the process where e happensI How would you define that order, so that it "extends" the HB

relation?I Although total, this order is somewhat arbitrary

I Actually, Lamport claims that the reason for Lamport clocks isprecisely to obtain a total order.

12/21

State Machine

I Indeed, a total order allows to solve any synchronization problem

Idea Specify the synchronization in terms of a state machine:Set of commands, CSet of states, SState transition function, t : C × S → S′

I I.e., the execution of a command, c, changes the currentstate s to a new state s′, formally: t(c, s) = s′

Synchronization is achieved, if all processes execute the sameset of commands in the same order

A process can execute a command timestamped T when ithas learned of all commands issued by all other processeswith timestamps less than or equal to T . The precise algo-rithm is straightforward, and we will not bother to describe it.

The problem is that the failure of a single process blocks thesystem

13/21

Use of Lamport Clocks: Total Order Multicast (1/2)

Problem How to ensure that if m and m′ are delivered by processes iand j , then they deliver m and m′ in the same order?

Solution Use extended Lamport timestamps to timestampmessages, and deliver the messages in the order of thesetimestampsDeliver vs. Receive this is similar to what happens with TCP to

ensure order in point-to-point communicationApplication layer

Middleware layer

Network layer

Message is delivered to application

Adjust local clock

Message is received

Adjust local clock and timestamp message

Application sends message

Middleware sends message

14/21

Use of Lamport Clocks: Total Order Multicast (2/2)Assumptions The communication channel is:

ReliableFIFOI Each process keeps its own Lamport clockI The only relevant events are the sending and receiving of

multicast messagesI Just before multicasting a message, the LC is incremented and

its value used to timestamp the messageI Upon receiving a message m, a process:

1. Inserts the message in a queue of messages ordered by theirextended Lamport timestamps;

2. Updates the Lamport clock to LC = max(TS(m),LC)

I A message is delivered to the application only when:I It is at the head of the queueI It is stable

I If there is a message on the queue from every other process

I To reduce the delivery delay, can use acknowledgments

15/21

Roadmap

The Happened-Before Relation

Lamport Clocks and Timestamps

Vector Clocks and Timestamps

16/21

Vector Clocks (1/3)

Observation The main limitation of Lamport clocks is that:L(e) < L(e′) 6⇒ e→ e′

Idea Use an array of timestamps, one per processorI Due to Mattern, Fidge and Schmuck

Rules Each process pi keeps its own vector Vi , which it updates asfollows:VC1 if e is not the receiving of a message, just increment Vi [i]VC2 if e is the receiving of a message m:

Vi [i] = Vi [i] + 1Vi [j] = max(Vi [j],TS(m)[j])

I Initially Vi [j] = 0, for all jI The timestamp of the sending event is piggybacked on the

corresponding message (TS(m) = V (send(m)))Basically

Vi [i] is the number of events timestamped by piVi [j] is the number of events in pj that pi knows about

17/21

Vector Clocks (2/3)

Let V and V ′ be vector timestampsVector Timestamps Comparison We define the relation < between

vector timestamps:V < V ′ iff ∀j : V [j] ≤ V ′[j] ∧ ∃i : V [i] < V ′[i]

Vector Clock Condition

e→ e′ ⇒ V (e) < V (e′)V (e) < V (e′) ⇒ e→ e′

On the other hand:

¬(V (e) < V (e′)) ∧ ¬(V (e′) < V (e))⇒ e||e′

Conclusion Vector timestamps can be used to determine whether theHB relation holds between any two pairs of eventsI Lamport clocks allow to conclude only if the HB does not hold

18/21

Vector Clocks (3/3)

m1

e

a b

c d

f

p2

p1

m2

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

(2,2,0)

(2,0,0)

(2,1,0)

(1,0,0)

I a and e are concurrent eventsI The main issue with vector clocks is that we need n timestamps

per event, whereas Lamport clocks need only oneI But there is no way to avoid it (Charron-Bost).

I Hidden communication channels can lead to anomalousbehaviorI I.e. to the violation of the Clock Condition

for both Lamport clocks and vector clocks.I Lamport claims that only synchronized (physical) clocks may

eliminate such anomalies

19/21

Vector Clocks Use: Causal Order Multicast (1/2)Problem How to ensure that if m→ m′ and process i delivers m′,

then it must have previously delivered mSolution Use vector clocks to timestamp messages, and deliver the

messages in the order of these timestamps (as defined above)I Each process keeps its own vector clockI The only relevant events are the sending and receiving of

multicast messagesI Just before multicasting a message, the sender updates its VC

after which it timestamps the messageI Upon receiving a message m, a receiver inserts the message

in the queue of received messagesI Process i delivers message m to the application only when:

Vi [j] ≥ TS(m)[j],∀j 6= k , where k is the sender of mVi [k ] = TS(m)[k ]− 1

After which it should update its VC (no need to increment Vi [i])

20/21

Vector Clocks Use: Causal Order Multicast (2/2)

P0

P1

P2

VC = (0,0,0)2 VC = (1,0,0)2

VC = (1,1,0)1

VC = (1,0,0)0 VC = (1,1,0)0

VC = (1,1,0)2

m

m*

ObservationsI VCi [i], counts the number of messages multicasted by piI VCi [j], i 6= j , counts the number of messages multicasted by pj

that pi has delivered to the applicationI The communication channels need to be reliable, but not FIFO.

Why?Question does the total order multicast protocol (with Lamport

timestamps) also ensure causal order?

21/21

Further Reading

I Tanenbaum and van Steen, Section 6.2 of Distributed Systems,2nd Ed.

I Leslie Lamport, Time, Clocks and the Ordering of Events in aDistributed System, Communications of the ACM 21(7): 558-565(1978)

I F. Mattern, "Virtual Time and Global States of DistributedSystems", in Proc. Workshop on Parallel and DistributedAlgorithms, Elsevier, pp. 215-226.

I C. Baquero and N. Preguiça, "Why logical clocks are easy",Communications of the ACM 59(4): 43-47 (2016)