06-clocks-virtualtime

Clocks and Virtual Time
Karthik Dantu
Steve Ko
Administrivia
• Assignment 2 will be up later today
• Friday: Project meetings
• Resource accounting
• Crowd-sourced wifi mapping
• Battery simulator
• Record/replay
Temporal Ordering
• Ubiquitous in systems
• Distributed Systems
• Collection of processes that communicate via
messages
• Message transmission delay in non-negligible
• Ordering non-trivial in distributed systems
Ordering in Distributed Systems
•
•
•
If a and b are events in
the same process, and a
occurred before b, or
Event a is send msg, and
b is rcv that msg, or
ab and bc, then
ac
Time
• Happened before 
• a  b iff
Logical Clocks
Ci - Non-negative monotonic number sequence for process i
Ci(b) is a number assigned to event b in process i
Clock condition:
For any event a, b:
If ab, then C(a) < C(b)
• Converse not true
• C1: If a and b are events in process Pi, and a occurs before
b, then C(a) < C(b)
• Tick between any two events in a process line
• C2: If a is sending the message by Pi, and b is receipt of that
message by Pj, then C(a) < C(b)
• Messages must cross a tick line
•
•
•
Time
Implementation Rules
• IR1: Each process Pi increments Ci between any two
successive events
• IR2: (a) If event a is the sending of a message m by
process Pi, then the message m contains timestamp
Tm = Ci(a)
(b) Upon receiving a message, process Pj sets Cj
greater than or equal to its present value and greater
than Tm
Total Ordering
• Break ties using an arbitrary total ordering (<<)
• Relation => defined as a=>b iff
• If a is an event in Pi and b is an event in Pj , then
a=>b if Ci(a) < Cj(b) or Ci(a) = Cj(b) and Pi << Pj
• ab implies a => b
Synchronization Problem
• Single shared resource to be “fairly” used across a
collection of processes and avoid conflict
• Fairness Conditions:
• Process granted the resource must release it
before use by others
• Requests must be granted in the order they were
made
• If every process granted the request eventually
releases it, every request must eventually be
granted
Implementation
• System of clocks with rules IR1 and IR2
• Total ordering of events using these clocks
• Request queue per process
• T0:P0
Algorithm
• Resource request: Process Pi sends msg Tm:Pi to every
other process
• When Pj receives this request it places it on its request
queue and sends ack to Pi
• Resource release: Process Pi removes msg Tm:Pi from its
request queue and sends release msg to all processes
• When Pj receives release msg, it removes Tm:Pi messages
from request queue
• Pi is granted resource iff
•
•
There is a Tm:Pi on request queue ordered before any other
request by relation =>
Pi received a msg from every other process time-stamped later
than Tm
Out of Band Events
• Let S be set of all events in our distributed system
• What if event k not in S triggers an event b?
• Strong clock condition:
For any event a, b in S:
If ab, then C(a) < C(b)
• Key difference: S is set of “real” events in physical
space-time
Physical Clocks
• Physical Clocks: Must run at approximately the correct rate
i.e., dCi/dt ~1
• Two rules for a correct physical clock
• Correctness
PC1: There exists a constant k << 1, such that
for all i: |dCi/dt – 1| < k
• Synchrony
PC2: For all i, j: |Ci(t) - Cj(t)| < e
Real-world Checks
• If ab, and Ci(a) = t and Cj(b) = t + u, then
Cj(t+u) – Ci(t) > 0 or e/(1-k) <= u
• IR1’: For each i, Pi does not receive a msg at
physical time t, then Ci is differentiable at t and
dCi/dt > 0
• IR2’: (a) If Pi sends a msg m at physical time t, them
m contains a timestamp Tm = Ci(t)
(b) Upon receiving msg m at t’, process Pj sets
Cj (t’) equal to maximum of (Cj (t’-0), Tm +um)
Virtual Time
• Non-negative monotonic, one-dimensional temporal
coordinate
• Distributed system: Collection of processes that
interact by sending/receiving msgs
• Msgs = (sender, virtual send time, receiver, virtual
receive time)
• Rule 1: Virtual send time < virtual receive time
• Rule 2: Virtual time of each event < virtual time of
next event in that process
Time Warp Mechanism
• Local Control
• Events executed in and messages received in
correct order
• Provides weakly correct implementation of
virtual time
• Global Control
• Guarantees system progress
• Provides strong correctness
Local Control: Implementation
• All transactions are look-aheads
• Process
• Name
• Local virtual clock
• State
• State queue
• Input queue
• Output queue
Local Control: Rollback
• If original arrived but not processed, anti-message
annihilates original
• If original has been processed, anti-message triggers
roll back including positive message
• If original is received after anti-message,
annihilation or rollback happens
Global Control: Global Virtual Time
• GVT at real time r is minimum of
• All virtual times in all virtual clocks at r
• Virtual send times in input queues not ack’ed
• Virtual send times of all messages sent but not
processed
• System estimates GVT ever so often
• Ensures overall progress of system
• Events before GVT committed and cannot be rolled
back