### Lecture 9: Vector Clocks, Mutual Exclusion

```Vector Clocks, Mutual
Exclusion
30 December 2014
Lecture 9
Slide Credits: Maarten van Steen
30 Dec 2014
ISE 437/SE 424: Distributed (Information) Systems
1
Topics for Today
• Logical Clocks
– Lamport logical clocks (review)
– Vector time stamps
• Mutual Exclusion
Source: TvS 6.2 – 6.3
30 Dec 2014
ISE 437/SE 424: Distributed (Information) Systems
2
The Happened-Before Relationship
Problem: We first need to introduce a notion of order in
before we can order anything.
The happened-before relation on the set of events in a
distributed system:
• If  and  are two events in the same process, and a
comes before , then a → .
• If a is the sending of a message, and  is the receipt of
that message, then  →
• If  →  and  → , then  →
Note: this introduces a partial ordering of events in a system
with concurrently operating processes.
30 Dec 2014
ISE 437/SE 424: Distributed (Information) Systems
3
Logical Clocks (1/2)
Problem: How do we maintain a global view on the system’s behavior
that is consistent with the happened-before relation?
Solution: attach a timestamp () to each event , satisfying the
following properties:
P1: If  and  are two events in the same process, and  → , then we
demand that   < ().
P2: If  corresponds to sending a message , and  to the receipt of that
message, then also   < ().
Problem: How to attach a timestamp to an event when there’s no global
clock  maintain a consistent set of logical clocks, one per process
30 Dec 2014
ISE 437/SE 424: Distributed (Information) Systems
4
Logical Clocks (2/2)
Solution
Each process  maintains a local counter  and adjusts this counter according to the
following rules:
1: For any two successive events that take place within  ,  is incremented by 1.
2: Each time a message  is sent by process  , the message receives a timestamp
=  .
3: Whenever a message  is received by a process  ,  adjusts its local counter
to max⁡{ ,   }; then executes step 1 before passing  to the application.
Property P1 is satisfied by (1);
Property P2 by (2) and (3).
Note: it can still occur that two events happen at the same time. Avoid this by
breaking ties through process IDs.
30 Dec 2014
ISE 437/SE 424: Distributed (Information) Systems
5
Logical Clocks - Example
1
2
3
1
2
3
0
0
0
0
0
0
8
10
6
8
10
12
16
20
12
16
20
18
24
30
18
24
24
32
40
24
32
40
30
40
50
30
40
50
36
48
60
36
48
42
56
70
42
61
70
64
80
48
69
80
54
72
90
70
77
90
60
80
100
76
85
100
6
48
1
4
30 Dec 2014
2
3
1
4
ISE 437/SE 424: Distributed (Information) Systems
2
3
30
60
6
Logical Clocks – Example
Note: Adjustments take place in the middleware layer:
30 Dec 2014
ISE 437/SE 424: Distributed (Information) Systems
7
Example: Totally Ordered Multicast (1/2)
Problem: We sometimes need to guarantee that concurrent updates on a
replicated database are seen in the same order everywhere:
• 1 adds \$100 to an account (initial value: \$1000)
• 2 increments account by 1%
• There are two replicas
Result: in absence of proper synchronization:
replica #1  \$1111, while replica #2  \$1110.
30 Dec 2014
ISE 437/SE 424: Distributed (Information) Systems
8
Example: Totally Ordered Multicast (2/2)
Solution:
• Process  sends timestamped message  to all others. The
message itself is put in a local queue  .
• Any incoming message at  is queued in  , according to its
timestamp, and acknowledged to every other process.
passes a message  to its application if:
(1)  is at the head of
(2) for each process  , there is a message  in  with a larger
timestamp.
Note: We are assuming that communication is reliable and FIFO
ordered.
30 Dec 2014
ISE 437/SE 424: Distributed (Information) Systems
9
Vector Clocks (1/2)
Observation: Lamport’s clocks do not guarantee that if () < ()⁡that
causally preceded :
Observation:
Event : 1 is received at ⁡ = ⁡16.
Event : 2 is sent at ⁡ = ⁡20.
We cannot conclude that  causally precedes .
30 Dec 2014
ISE 437/SE 424: Distributed (Information) Systems
10
Vector Clocks (2/2)
Solution:
•
Each process  has an array  [1. . ], where  []⁡denotes the
number of events that process  knows have taken place at process

•
When  sends a message , it adds 1 to  [], and sends  ⁡along
with  as vector timestamp (). Result: upon arrival, recipient
knows  ’s timestamp.
•
When a process  delivers a message  that it received from  with
vector timestamp (), it
1) updates each  ⁡[] to max⁡{ [], ()[]} for each
2) increments  [] by 1.
Question: What does  [] =  mean in terms of messages sent and
30 Dec 2014
ISE 437/SE 424: Distributed (Information) Systems
11
Vector and Lamport Clocks
Lamport Clocks
Vector clocks
Rule 1: Each process has its own
version of the global clock
Rule 1: Each process has its own
clock and a version of every
other processes’ clock.
Rule 2: Each process increments
its global clock version when it
performs an internal event or
sends a message (which
includes a timestamp)
Rule 3: When a process receives a
message from another process
it updates its global clock
version if the received
timestamp is larger.
30 Dec 2014
Rule 2: Each process increments
its own clock when it sends or
Rule 3: When a process receives a
message from another process
it updates its version of the
other clocks’ timestamps if the
received timestamp is larger
ISE 437/SE 424: Distributed (Information) Systems
12
Vector Clock Example
1 1
1 0
2 0
2 0
3 0
3 0
1 2
1 3
1 1
2 0
2 3
2 0
3 0
3 4
3 0
1 2
2 3
3 4
2
1
1 2
2 0
1
3 0
4
2 3
1 0
1 2
1 2
2 0
2 1
2 2
3 0
3 0
3 2
1 2
2 3
3 2
1 1
1 2
2 0
2 3
3 4
1 2
3 2
5
1 2 1 1
1 1
1 0
2 3 2 0
2 0
2 0
3 3 3 2
3 1
3 0
30 Dec 2014
2
3
3 2
3
ISE 437/SE 424: Distributed (Information) Systems
13
Vector Clock Example
m1
m2
1 1
2 0
2 3
3 0
3 2
1 2
1 2
2 0
3 0
1 1
m3
m4
1 2
2 0
3 2
30 Dec 2014
m5
2 3
3 4
1.
2.
3.
4.
1 < 2
1 < 3
1 < 4
1 < 5
5. 2 <> 3
6. 2 < 4
7. 2 < 5
8. 3 < 4
9. 3 < 5
10. 4 < 5
ISE 437/SE 424: Distributed (Information) Systems
14
Causally Ordered Multicasting (1/2)
Observation: We can now ensure that a message is
delivered only if all causally preceding messages have
Adjustment:  increments  [] only when sending a
message, and  “adjusts”  when receiving a message
(i.e., effectively does not change  []).
postpones delivery of  until:
• ()[] =  [] + 1.
•    ≤  [] for  ≠
30 Dec 2014
ISE 437/SE 424: Distributed (Information) Systems
15
Causally Ordered Multicasting (2/2)
Example 1:
Example 2: Take VC2 = [0,2,2], () = [1,3,0] from 0 .
What information does 2 have, and what will it do when
receiving  (from 0 )?
30 Dec 2014
ISE 437/SE 424: Distributed (Information) Systems
16
Causally Ordered Multicast 1
1 1 1 0
2 0 2 0
1
3 0 3 0
1 1 1 2
3
1
1 1
1 2
2 0
2 0
3 0
3 1
2 0 2 0
2
1 0 1 1 1 1
2 0 2 0 2 0
3 0 3 0 3 1
1 2
delayed
wait
2 0
3 1
3 1 3 1
1 1
2 0
3 1
2
1 2
1 1
1 1
1 0
2 0
2 0
2 0
2 0
3 1
3 1
3 0
3 0
30 Dec 2014
3
ISE 437/SE 424: Distributed (Information) Systems
17
Causally Ordered Multicast 2
1 1 1 0
2 0 2 0
1
3
1
3 0 3 0
1 2 1 2
1 1
1 2
2 0
2 0
3 0
3 0
2
1 0 1 1 1 2
2 0 2 0 2 0
3 0 3 0 3 0
1 2
2 0 2 0
2 0
3 0 3 1
3 1
1 1
2 0
delayed
3 1
2
1 2
1 1
1 1
1 0
2 0
2 0
2 0
2 0
3 1
3 1
3 0
3 0
30 Dec 2014
3
ISE 437/SE 424: Distributed (Information) Systems
18
Vector Clocks and COM
Vector clocks
Causally Ordered Multicast
Rule 1: Each process has its own
clock and a version of every other
processes’ clock.
Rule 1: Each process has its own
clock and a version of every other
processes’ clock.
Rule 2: Each process increments its
own clock when it sends or
Rule 2: Each process increments its
own clock when it sends a
message.
Rule 3: When a process receives a
message from another process it
updates its version of the other
clocks’ timestamps if the received
timestamp is larger
Rule 3: When a process receives a
message from another process it
updates its version of the sender’s
timestamp.
Rule 4: A message is delivered only if
it is “next in line”:
1. It’s the next expected one for the
sender
2. The message’s timestamp is less
than or equal to the local clock.
30 Dec 2014
ISE 437/SE 424: Distributed (Information) Systems
19
So Far
• Physical Clocks
– GPS
– Synchronization
• Logical Clocks
– Lamport logical clocks
– Vector time stamps
• Mutual Exclusion
30 Dec 2014
ISE 437/SE 424: Distributed (Information) Systems
20
Mutual Exclusion
Problem: A number of processes in a distributed system want exclusive
Basic solutions:
• Via a centralized server.
• Completely decentralized, using a peer-to-peer system.
• Completely distributed, with no topology imposed.
• Completely distributed along a (logical) ring.
Centralized: Really simple:
30 Dec 2014
ISE 437/SE 424: Distributed (Information) Systems
21
Decentralized Mutual Exclusion
Principle: Assume every resource is replicated  times, with each replica

having its own coordinator → access requires a majority vote from ⁡ > 2
coordinators. A coordinator always responds immediately to a request.
Assumption: When a coordinator crashes, it will recover quickly, but will
have forgotten about permissions it had granted.
Δt
Issue: How robust is this system? Let  =  denote the probability that a
coordinator crashes and recovers in a period Δ while having an average
lifetime  → probability that  out  coordinators reset:

=
=2−

1−

−
With ⁡ = ⁡0.001, ⁡ = ⁡32, ⁡ = ⁡0.75,  < 10−40
30 Dec 2014
ISE 437/SE 424: Distributed (Information) Systems
22
Conclusion
• Physical Clocks
– GPS
– Synchronization
• Logical Clocks
– Lamport logical clocks
– Vector time stamps
• Mutual Exclusion
30 Dec 2014
ISE 437/SE 424: Distributed (Information) Systems
23
```