Upcoming SlideShare
×

# Clocks

• 1,951 views

• Comment goes here.
Are you sure you want to
Be the first to comment

Total Views
1,951
On Slideshare
0
From Embeds
0
Number of Embeds
0

Shares
87
0
Likes
1

No embeds

### Report content

No notes for slide

### Transcript

• 1. Logical Clocks Sunetri P. Dasari Summer 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 Multicasting
• Updating a replicated database and leaving it in an inconsistent state.
• 12. Totally-Ordered Multicasting
• 13. Scalar Logical Time: Pros and Cons
• 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.
• 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 P i maintains a vector V i with the following two properties:
• V i [i] = no. of events that have occurred so far at P i
• If V i [j] = k, then P i knows that k events have occurred at P j
• Occurrence of an event at process P i causes an increment in V i [i] (i’th entry in its own vector clock)
• When P i sends a message to P j we have
• V j [k] = max (V j [k], V i [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] p 0 p 1 p 2 p 3 [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 Consistency
• The system of vector clocks is strongly consistent
• Every event is assigned a timestamp in such a manner that satisfies the clock consistency condition :
• if e 1  e 2 then vt( e 1 ) < vt( e 2 )
• If the protocol satisfies the following condition as well, then the clock is said to be strongly consistent:
• if vt( e 1 ) < vt( e 2 ) then e 1  e 2
• 21. Matrix Time
• A process P i maintains a matrix
• mt i [1…n, 1…n] where
• mt i [i, i] denotes the logical clock of P i
• mt i [i, j] denotes the latest knowledge that P i has about the local clock, mt J [j, j] of P j (row i is the vector clock of P i )
• mt i [j, k] represents what P i knows about the latest knowledge that P J has about the local logical clock mt k [k, k] of P k.
• mt i [j, k] = mt J [j, k]
• 22. Matrix Time Protocol
• At process P i :
• Before executing an event, P i updates its local logical time as follows:
• mt i [i, i] = mt i [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 P j , P i updates its matrix clock as follows:
• for 1 <= k <= n: mt i [i, k] = max(mt i [i, k] , mt[j, k] )
• for 1 <= k <= n
• for 1 <= q <= n
• mt i [k, q] = max(mt i [k, q] , mt[k, q] )
• 3. mt i [i, i] = mt i [i, i] + d (d > 0)
• 23. Matrix Clock Consistency
• The system of matrix clocks is strongly consistent
• Every event is assigned a timestamp in such a manner that satisfy the clock consistency condition :
• if e 1  e 2 then mt( e 1 ) < mt( e 2 )
• If the protocol satisfies the following condition as well, then the clock is said to be strongly consistent:
• if mt( e 1 ) < mt( e 2 ) then e 1  e 2
• 24. Ordered Message Delivery: Issues
• Should ordering be done at the message communication layer, or handled by the application ?
• Problems at the communication layer
• Only potential causality is captured as this layer cannot tell what the message contains
• Not all causality may be captured (external communication issues)
• Problems with application-level solutions
• 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