Lecture 13 Synchronization (cont)

1
Lecture 13Synchronization (cont)
2
Logistics

• Last quiz
• Max 69 / Median 52 / Min 24
• In a box outside my office
• Project
• P01 deadline in a week
• Coding session / office hours Wednesday?
• Non-blocking IO lecture Nov 4th.
• Next quiz
• Tuesday 16th.
• Remembrance day Nov 11th.
• No class on Nov 18th

3
Today

• Clocks can not be perfectly synchronized.
• What can I do in these conditions?
• Figure out how large is the drift
• 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 examples
• Two shooters in a multiplayer online game shoot
  (and kill) the same target.
• Need to decide who gets the point?
• Object A is observed from two vantage points S1
  and S2 at local times t1 and t2.
• Need to aggregate everything into one consistent
  view. Which way is A moving? How fast?
• Fairness vs. correctness tradeoffs?

5
Happens-before relation

• Problem We 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 an event of sending a message by a
  process, and b
• receiving same message by another
  process then a ? b
• Notation a ? b, when all participants agree that
  b occurs after a.
• Property transitive
• Two events are concurrent if nothing can be said
  about the order in which they happened (partial
  order)

6
Logical clocks

• Problem How do we maintain a global view on the
  systems behavior that is consistent with the
  happened-before relation?
• 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
• Idea 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) 1 then passes 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
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
9
Architectural view

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

10
Example use Totally ordered group communication

• 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
11
Totally ordered group communication (cont)

• Solution
• Each message is timestamped with local logical
  time then multicasted
• When multicasted, also message logically sent to
  the sender itself
• When receiving, the middleware layer
• Adds message to a queue
• Acknowledges (using multicast) the message
• Delivers from queue to application only when all
  acks are received

12
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 the multicasted 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
13
More quiz-like questions

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

14
So far

• Physical clocks
• Two applications
• Provide at-most-once semantics
• Global Positioning Systems
• Logical clocks
• Where only ordering of events matters