260 likes | 369 Views
SYNCHRONIZATION TIME, EVENT, CLOCKS PART 3. Lecture 8. SE-9048 Concurrency & Distributed System Huma Ayub ( huma.ayub@uettaxila.edu.pk ) Assistant Professor Software Engineering Department. Where do We Stand in Synchronization Chapter?. Previous lecture.
E N D
SYNCHRONIZATION TIME, EVENT, CLOCKS PART 3 Lecture 8 SE-9048 Concurrency & Distributed System Huma Ayub (huma.ayub@uettaxila.edu.pk) Assistant Professor Software Engineering Department
Where do We Stand in Synchronization Chapter? Previous lecture • Time Synchronization • Physical Clock Synchronization (or, simply, Clock Synchronization) • Here, actual time on the computers are synchronized • Logical Clock Synchronization • Computers are synchronized based on the relative ordering of events • Mutual Exclusion • How to coordinate between processes that access the same resource? • Election Algorithms • Here, a group of entities elect one entity as the coordinator for solving a problem Today’s lecture Next lecture
BackgroundRevisited[1] • Synchronization: coordination of actions between processes. • Processes are usually asynchronous, (operate independent of events in other processes) • Sometimes need to cooperate/synchronize • For mutual exclusion • For event ordering (was message x from process P sent before or after message y from process Q?)
Revisited[2] • Synchronization in centralized systems is primarily accomplished through shared memory • Event ordering is clear because all events are timed by the same clock • Synchronization in distributed systems is harder • No shared memory • No common clock • Is it possible to synchronize clocks in a distributed system?
Revisited[3] Physical Clocks • Physical clock example: counter + holding register + oscillating quartz crystal • The counter is decremented at each oscillation • Counter interrupts when it reaches zero • Reloads from the holding register • Interrupt = clock tick (often 60 times/second)
Clock Skew Revisited[4] • In a distributed system each computer has its own clock • Each crystal will oscillate at slightly different rate. • Over time, the software clock values on the different computers are no longer the same.
Clock Synchronization Algorithms* • In a distributed system one machine may have a WWV receiver and some technique is used to keep all the other machines in synch with this value. • Or, no machine has access to an external time source and some technique is used to keep all machines synchronized with each other, if not with “real” time.
Clock Synchronization Algorithms • Network Time Protocol (NTP): • Objective: to keep all clocks in a system synchronized to UTC time (1-50 msec accuracy) – not so good in WAN • Uses a hierarchy of passive time servers • The Berkeley Algorithm: • Objective: to keep all clocks in a system synchronized to each other (internal synchronization) • Uses active time servers that poll machines periodically • Cristian’s method • This algorithm is well suited to systems in which one machine (the time server) has a WWV receiver and the other machines stay synchronized with it.
Three Philosophies of Clock Synchronization • So far we have observed that …….. • Try to keep all clocks synchronized to each other, even if they vary somewhat from UTC time • But ????
Why Logical Clocks? • Observation: if two processes (running on separate processors) do not interact, it doesn’t matter if their clocks are not synchronized. • Observation: When processes do interact, they are usually interested in event order, instead of exact event time. • Conclusion: Logical clocks are sufficient for many applications
Logical Clocks • Lamport (in 1978) showed that: • Two papers: • Time, Clocks, and the Ordering of Events in a Distributed System, Lamport, 1978 • Distributed Snapshots: Determining Global States of Distributed Systems, Chandy and Lamport, 1985
Logical Clocks • Logical clocks are used to define an order of events without measuring the physical time at which the events occurred • We will study two types of logical clocks • Lamport’s Logical Clock (or simply, Lamport’s Clock) • Vector Clock
Formalization • The distributed system consists of n processes, p1, p2, …pn • Each pi executes on a separate processor • No shared memory • Each pi has a state si • Process execution: a sequence of events • Changes to the local state • Message Send or Receive
Lamport’s Logical Time • Lamport defined a “happens-before” relation between events in a process. • "Events" are defined by the application. The granularity may be as uneven as a procedure or as fine-grained as a single instruction.
Happened Before Relation (a b) • a b: • 1) in the same [sequential] process, 2) send, receive in different processes, (messages) 3) transitivity: if a b and b c, then a c • If a b, then a and b are causally related; i.e., event a potentially has a causal effect on event b.
Concurrent Events • Happens-before defines a partial order of events in a distributed system. • Some events can’t be placed in the order • a and b are concurrent (a || b) if !(a b) and !(b a). • If a and b aren’t connected by the happened-before relation, there’s no way one could affect the other.
Logical Clocks • Needed: method to assign a “timestamp” to event a (call it C(a)), even in the absence of a global clock • The method must guarantee that the clocks have certain properties, in order to reflect the definition of happens-before. • Define a clock (event counter), Ci, at each process (processor) Pi. • When an event a occurs, its timestamp ts(a) = C(a), the local clock value at the time the event takes place.
Correctness Conditions • If a and b are in the same process, anda b then C(a) < C(b) • If a is the event of sending a message from Pi, and b is the event of receiving the message by Pj, then Ci (a) < Cj (b). • The value of C must be increasing (time doesn’t go backward). • Result: any clock corrections must be made by adding a positive number to a time.
Implementation Rules • Between any two successive events a & b in Pi, increment the local clock (Ci = Ci + 1) • thus Ci(b) = Ci(a) + 1 • When a message m is sent from Pi, set its time-stamp tsm to Ci, the time of the send event after following previous step. • When the message is received at Pj the local time must be greater than tsm . The rule is (Cj = max{Cj, tsm} + 1). • The clock time C must always go forward (increasing), and never backward (decreasing
Implementation of Lamport’s Clock • Each process Pi maintains a local counter Ci and adjusts this counter according to the following rules: • For any two successive events that take place within Pi, Ci is incremented by 1 • Each time a message m is sent by process Pi , the message receives a timestamp ts(m) = Ci • Whenever a message m is received by a process Pj, Pj adjusts its local counter Cj to max(Cj, ts(m)) + 1 C0=0 C0=1 C0=2 P0 m:2 C1=0 C1=3 P1 C2=0 P2
Lamport’s Logical Clocks(1) Figure 6-9. (a) Three processes, each with its own clock. The clocks “run” at different rates. Event a: P1 sends m1 to P2 at t = 6, Event b: P2 receives m1 at t = 16.If C(a) is the time m1 was sent, and C(b) is the time m1 is received, do C(a) and C(b) satisfy the correctness conditions ?
Lamport’s Logical Clocks (2) Figure 6-9. (b) Lamport’s algorithm corrects the clocks. Event c: P3 sends m3 to P2 at t = 60Event d: P2 receives m3 at t = 56Do C(c) and C(d) satisfy the conditions?
Lamport’s algorithm Algorithm allows us to maintain time ordering among related events • Partial ordering • Lamport’s Clock ensures that if ab, then C(a) < C(b) • However, it does not say anything about any two events a and b by comparing their time values • For any two events a and b, C(a) < C(b) does not mean that ab
Lamport’s Clock • A total order of events (“=>”) can be obtained as follows: • Note: it can still occur that two events happen at the same time. Avoid this by breaking ties through process IDs. • If a is any event in process Pi , and b is any event in process Pk , • then a Þb if and only if either: • Ci (a) < Ck (b) or • Ci (a) = Ck (b) and Pi << Pk • where “<<“ denotes a relation that totally orders the processes to • break ties