1

Logical Clocks

Sunetri P. DasariSummer 2005

CSC8980 Distributed Systems Instructor: Sushil K. Prasad

2

What are Logical Clocks ?

• A logical clock is a mechanism for capturing chronological and causal relationships in a distributed system.

• Clock Implementation– Data structure– Clock Update Protocol

• Logical clock algorithms of note are:– Scalar clocks– Vector clocks– Matrix clocks

3

Lamport’s Contribution (1/2)

• Notion of logical time as opposed to absolute time

• Partial ordering of events by occurrence– Causally Related Events

• If event A happens before event B, then A causally affects B.

– Concurrent Events• Two distinct events A and B are concurrent if A does not happen before B

and B does not happen before A. That is, the events have no causal relationship.

• Extend “Happens Before” relation to provide a consistent total ordering of all events in a distributed system

Example: make utility – creation times of input.c and input.o

4

Lamport’s Contribution (2/2)

Lamport introduced a system of logical clocks in order to make the “happens before” relation possible.

• Each process P in the system has its own clock C.

• For every event ‘a’ in the process, C can be looked at as a function that assigns a number C(a), which is the timestamp of the event ‘a’ in process P.

• These numbers are not in any way related to physical time -- that is why they are called logical clocks.

5

Happens Before Relation “->”

• If ‘a’ and ‘b’ are two events in the same process, and ‘a’ occurs before ‘b’, then a -> b is true.

• If ‘a’ is the event of sending a message by one process and ‘b’ is the event of receiving the message by another process, then a -> b is true.

• If a -> b and b -> c, a -> c is true.

• If a (not) -> b and b (not) -> a, then and b are concurrent.

6

Logical Clocks (1/2)

7

Logical Clocks (2/2)How do we maintain a consistent set of logical clocks, one per process ?

8

Three processes, each with its own clock. The clocks run at different rates.

9

Lamport's algorithm corrects the clocks.

10

Total Ordering with Logical Clocks

11

Totally-Ordered MulticastingUpdating a replicated database and leaving it in an inconsistent state.

12

Totally-Ordered Multicasting

13

Scalar Logical Time: Pros and Cons

Advantages

We get a total ordering of events in the system. All the benefits gained from knowing the causality of events in the system apply.

Small overhead: one integer per process.

Disadvantage

Clocks are not strongly consistent: clocks lose track of the timestamp of the event on which they are dependent on. This is because we are using a single integer to store the local and logical time.

14

What are Vector Timestamps ?

• Lamport timestamps do not capture causality

A vector timestamp VT(a) assigned to an event ‘a’ has the property that if VT(a) < VT(b) for some event ‘b’ , then event ‘a’ is known to causally precede event ‘b’.

• Extend logical timestamps into a list of counters, one per process in the system

• Again, each process keeps its own copy

15

What are Vector Timestamps ?

Each process Pi maintains a vector Vi with the following two properties:

1. Vi[i] = no. of events that have occurred so far at Pi

2. If Vi[j] = k, then Pi knows that k events have occurred at Pj

• Occurrence of an event at process Pi causes an increment in Vi[i] (i’th entry in its own vector clock)

• When Pi sends a message to Pj we have Vj[k] = max (Vj[k], Vi[k] ) (element-by-element)

16

Illustration of Vector timestamps

[1,0,0,0] [2,0,0,0]

[0,0,1,0]

[2,1,1,0]

p0

p1

p2

p3

[0,0,0,1]

[2,2,1,0]

[2,1,1,1]

[1,0,0,0]

[1,0,1,0]

[2,0,1,0]

[2,2,1,1]

[2,2,1,0]

17

Vector timestamps accurately represent happens-before relation

• Define VT(e)<VT(e’) if, – for all i, VT(e)[i]<VT(e’)[i], and – for some j, VT(e)[j]<VT(e’)[j]

• Example: if VT(e)=[2,1,1,0] and VT(e’)=[2,3,1,0] then VT(e)<VT(e’)

• Notice that not all VT’s are “comparable” under this rule: consider [4,0,0,0] and [0,0,0,4]

18

Vector Timestamps (1/2)

19

Vector Timestamps (2/2)

20

Vector Clock ConsistencyThe system of vector clocks is strongly consistent• Every event is assigned a timestamp in such a

manner that satisfies the clock consistency condition:

if e1e2 then vt(e1) < vt(e2)

• If the protocol satisfies the following condition as well, then the clock is said to be strongly consistent:

if vt(e1 ) < vt(e2 ) then e1e2

21

Matrix TimeA process Pi maintains a matrix

mti[1…n, 1…n] where

– mti[i, i] denotes the logical clock of Pi

– mti[i, j] denotes the latest knowledge that Pi has about the local clock, mtJ[j, j] of Pj (row i is the vector clock of Pi)

– mti[j, k] represents what Pi knows about the latest knowledge that PJ has about the local logical clock mtk[k, k] of Pk.

mti[j, k] = mtJ[j, k]

22

Matrix Time Protocol

At process Pi:– Before executing an event, Pi updates its local logical

time as follows:mti[i, i] = mti[i, i] + d (d > 0)

– Each sender process piggybacks a message m with its matrix clock value at sending time. Upon receiving such a message (m, vt) from Pj, Pi updates its matrix clock as follows:1. for 1 <= k <= n: mti[i, k] = max(mti[i, k] , mt[j, k] )2. for 1 <= k <= n

for 1 <= q <= n

mti[k, q] = max(mti[k, q] , mt[k, q] )

3. mti[i, i] = mti[i, i] + d (d > 0)

23

Matrix Clock ConsistencyThe system of matrix clocks is strongly consistent• Every event is assigned a timestamp in such a

manner that satisfy the clock consistency condition:

if e1 e2 then mt(e1 ) < mt(e2)

• If the protocol satisfies the following condition as well, then the clock is said to be strongly consistent:

if mt(e1 ) < mt(e2 ) then e1e2

24

Ordered Message Delivery: Issues• Should ordering be done at the message

communication layer, or handled by the application ?

• Problems at the communication layer1. Only potential causality is captured as this layer

cannot tell what the message contains2. Not all causality may be captured (external

communication issues)

• Problems with application-level solutions1. Developer is forced to deal with ordering which

may not relate to the core functionality of the app

25

End-to-end Argument• Saltzer et al., 1984

“A function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible.”

Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.

26

References[1] Distributed Systems: Principles and Paradigms

Andrew S. Tanenbaum, Maarten van Steen

[2] Leslie Lamport. Time, Clocks and the Ordering of Events in Distributed Systems. CACM, Vol. 27, No. 7, July 1978, pp. 558-565

[3] M. Raynal, M. Singhal. Logical Time: Capturing Causality in Distributed Systems. IEEE Computer, February 1996, pp. 49-56

[4] JH Saltzer, DP Reed, and DD Clark. End-to-end arguments in system design.ACM Transactions on Computer Systems, pages 277-288, 1984