Lecture 12-13 Synchronization - logical clocks

1
Lecture 12-13Synchronization- logical
clocks
2
Logistics

• Project
• P01 deadline on Monday October 31st.
• Office hours
• Wednesday afternoon (send me email)
• Thursday after class
• P02 deadline on Monday November 14th.
• Next quiz
• Thursday 17th.

3
Today

• Clocks can not be perfectly synchronized.
• What can I do in these conditions?
• Figure out how large exactly the drift is
• Example GPS systems
• Design the system to take drift into account
• Example Server design to provide at-most-once
  semantics
• Do not use physical clocks!
• Consider only event order - Logical clocks

4
Logical clocks -- Time Revisited

• Whats important?
• The precise time an event occurred?
• The order in which events occur?
• Our example
• Two shooters in a multiplayer online game shoot
  (and kill) the same target.
• Need to decide who gets the point?

5
Happens-before relation

• Problem We first need to introduce a notion of
  ordering before we can order anything.
• The happened-before relation on the set of events
  in a distributed system
• if a and b in the same process, and a occurs
  before b,
• then a ? b
• if a is the event of sending a message by a
  process, and b
• receiving same message by another
  process then a ? b
• Property transitive
• Notation a ? b, when all participants agree that
  b occurs after a.
• Two events are concurrent if nothing can be said
  about the order in which they happened (partial
  order)

6
Logical clocks

• Issue How do we maintain a global view on the
  systems behavior that is consistent with the
  happened-before relation?
• Towards a solution attach a timestamp C(e) to
  each event e, satisfying the following
  properties
• P1 If a and b are two events in the same
  process, and a?b, then we demand that C(a) lt
  C(b).
• P2 If a corresponds to sending a message m, and
  b to the receipt of that message, then also C(a)
  lt C(b).
• Note C must only increase
• Problem Need to attach timestamps to all events
  in the system (consistent with the rules above)
  when theres no global clock
• maintain a consistent set of logical clocks, one
  per process.

7
Logical clocks (cont) -- Lamports Approach

• Solution Each process Pi maintains a local
  counter Ci and adjusts this counter according to
  the following rules
• (1) For any two successive events that take place
  within process Pi, the counter Ci is incremented
  by 1.
• (2) Each time a message m is sent by process Pi
  the message receives a timestamp ts(m) Ci
• (3) Whenever a message m is received by a process
  Pj, Pj adjusts its local counter Cj to maxCj,
  ts(m) then executes step 1 before passing m 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.

8
Updating Lamports logical timestamps
Physical Time
p 1
8
0
7
8
3
p 2
0
3
6
p 3
4
0
10
9
5
4
7
p 4
0
5
6
7
Clock Value
n
timestamp
Message
9
Quiz-like question

• Notation timestamp(a) is the Lamport logical
  clock associated with event a
• By definition if a ? b gt timestamp(a) lt
  timestamp(b)
• (if a happens before b, then Lamport_timestamp(a)
  lt Lamport_timestamp(b))
• Q is the converse true?
• That is if timestamp(a) lt timestamp(b) gt
  a ? b
• (If Lamport_timestamp(a) lt Lamport_timestamp(b),
  it does NOT imply that a happens before b

10
Example

Physical Time
1
2
p 1
8
0
7
1
8
3
p 2
0
2
2
3
6
p 3
4
0
10
9
3
5
4
7
p 4
0
5
6
7
Clock Value
n
timestamp
Message
Note Lamport Timestamps 3 lt 7, but event with
timestamp 3 is concurrent to event with timestamp
7, i.e., events are not in happen-before
relation.
11
Architectural view

• Middleware layer in charge of
• Local management of logical clocks
• Stamping messages with (logical) clock times,
  reading timestamps
• Message ordering (if necessary)

12
Example use

• Two accounts
• Initial state 100 account balance
• Update 1 add 100
• Update 2 add 1 monthly interest
• Updates need to be performed in the same order at
  the two replicas?

Middleware layer that provides total ordering
13
Totally ordered group communication (cont)

• Setup (for simplicity)
• Symmetry all members are both
• senders and receivers
• A one-to-many communication substrate

14
Totally ordered group communication (cont)

• Setup (for simplicity)
• Symmetry all members are both
• senders and receivers
• A one-to-many communication substrate
• Sketch of a solution
• Middleware at each member maintains an ordered
  queue of received messages that have not yet been
  delivered to the application.
• Main issue when to deliver to application such
  that, at all endpoints, messages are delivered in
  the same order.
• Each message is timestamped with local logical
  time then multicasted
• When multicasted, also message logically sent to
  the sender itself
• When receiving a message, the middleware layer
• Adds message to local queue
• Acknowledges (using multicst) the message
• Deliver from top of queue to application only
  when all acks are received

15
Totally Ordered Multicast Algorithm
Sending / Receiving

• Process Pi sends timestamped message msgi to all
  others. The message itself is put in a local
  queue queuei.
• Any incoming message at Pk is queued in queuek,
  according to its timestamp, and acknowledged to
  every other process.
• Pk delivers a message msgi to its application if
• msgi is at the head of queuek
• for each process Px, there is a message msgx in
  queuek with a larger timestamp.
• Guarantee all messages are delivered in the same
  order at all destinations
• Nothing is guaranteed about the actual order!
• Note We assume that communication is reliable
  and FIFO ordered.
• Quiz-like questions
• What happens if we drop channel reliability
  assumption?
• What happens if we drop channel FIFO assumption?

Deliver to application
16
quiz-like questions

• Whats the complexity of the protocol in terms of
  number of messages
• What happens if we drop channel reliability
  assumption?
• Does the protocol still work?
• What happens if we drop channel FIFO assumption?
• Does the protocol still work?
• How would you change the previous protocol to
  still work correctly without this assumption?
• Assume you have a bound on message propagation
  time in the network. Design a protocol that
  provides total ordering (and generates less
  traffic)

17
(No Transcript)
18
Causality

• Lamport timestamps dont capture causality
• Example news postings have multiple
• independent threads of messages
• To model causality vector timestamps
• Intuition each item in vector logical clock for
  one causality thread.

19
Example Vector Timestamsps

Physical Time
p 1
0,0,0,0
p 2
0,0,0,0
p 3
0,0,0,0
p 4
0,0,0,0
Vector logical clock
n,m,p,q
(vector timestamp)
Message
20
Vector clocks

• Each process Pi has an array VCi 1..n of clocks
  (all initialized at 0)
• VCi j denotes the number of events that process
  Pi knows have taken place at process Pj.
• Pi increments VCi i when an event occurs or
  when sending
• Vector value is the timestamp of the event
• When sending
• Messages sent by VCi include a vector timestamp
  vt(m).
• Result upon arrival, recipient knows Pis
  timestamp.
• When Pj receives a message sent by Pi with vector
  timestamp ts(m)
• for k ? j updates each VCj k to maxVCj k,
  ts(m)k
• Note vector timestamps require a static notion
  of system membership
• Question What does VCij k mean in terms of
  messages sent and received?

21
Comparing vector timestamps

• VT1 lt VT2, (happens before relationship 1 ? 2)
• iff forall j (1 j n) such that VT1j
  VT2 j
• and
• exists j (1 j n) such that VT1j lt
  VT2 j
• VT1 is concurrent with VT2
• iff (not VT1 lt VT2 AND not VT2 lt VT1)

22
Quiz like problem

• Show that
• a ? b if and only if vectorTS(a) lt
  vectorTS(b)

23
Extending group communication

• ASSUMPTIONS
• messages are multicast to named process groups
• reliable and fifo channels (from a given source
  to a given destination)
• processes dont crash (failure and restart not
  considered)
• processes behave as specified e.g., send the same
  values to all processes (i.e., we are not
  considering Byzantine behaviour)

may specify delivery order to message
service e.g. total order, FIFO order, causal
order (last time we looked at total order)
application process
Messaging middleware
may reorder delivery to application by buffering
messages
assume FIFO from each source (done at lower
levels)
OS comms. interface
24
FIFO multicast

• FIFO (or sender ordered) multicast Messages are
  delivered in the order they were sent by any
  single sender
• Nothing guaranteed for ordering of messages sent
  by two different senders

a
e
P1 P2 P3 P4
25
FIFO multicast

• FIFO (or sender ordered) multicast Messages are
  delivered in the order they were sent by any
  single sender
• Nothing guaranteed for ordering of messages sent
  by two different senders

a
e
P1 P2 P3 P4
b
c
d
delivery of c to P1 is delayed until after b is
delivered
26
Implementing FIFO multicast

• Basic reliable multicast algorithm has this
  property
• Without failures all we need is to run it on FIFO
  channels (like TCP)
• Later dealing with node failures

27
Causal multicast

• Causal (or happens-before ordering)
• If send(a) ? send(b) (i.e., there was some causal
  relationship)
• then deliver(a) occurs before deliver(b) at
  common destinations

a
P1 P2 P3 P4
b
28
Ordering properties Causal

• Causal or happens-before ordering
• If send(a) ? send(b) then deliver(a) occurs
  before deliver(b) at common destinations

a
P1 P2 P3 P4
b
c
delivery of c to P1 is delayed until after b is
delivered
29
Ordering properties Causal

• Causal or happens-before ordering
• If send(a) ? send(b) then deliver(a) occurs
  before deliver(b) at common destinations

a
e
P1 P2 P3 P4
b
c
d
e is sent (causally) after b and c
e is sent concurrently with d
30
Ordering properties Causal

• Causal or happens-before ordering
• If send(a) ? send(b) then deliver(a) occurs
  before deliver(b) at common destinations

a
e
P1 P2 P3 P4
b
c
d
delivery of c to P1 is delayed until after b is
delivered
delivery of e to P3 is delayed until after bc
are delivered
delivery of e and d to P2 and P3 in any relative
order (concurrent)
31
Causally ordered multicast
32
Implementing causal order multicast

• Start with a FIFO multicast
• We can strengthen this into a causal multicast by
  adding vector time
• No additional messages needed!
• Advantage FIFO and causal multicast are
  asynchronous
• Sender doesnt get blocked and can deliver a copy
  to itself without stopping to learn a safe
  delivery order
• Lower overhead

33
So far

• Physical clocks
• Two applications
• Provide at-most-once semantics
• Global Positioning Systems
• Logical clocks
• Where only ordering of events matters
• Next Other coordination primitives
• Mutual exclusion
• Leader election