1. 6 SYNCHRONIZATION

2. introduction processes synchronize –exclusive access. –agree on the ordering of events much more difficult compared to synchronization in uniprocessor or multiprocessor systems Synchronization –based on actual time –relative ordering matters –election algorithms

3. contents 6.1 CLOCK SYNCHRONIZATION 6.2 LOGICAL CLOCKS 6.3 MUTUAL EXCLUSION 6.4 GLOBAL POSITIONING OF NODES 6.5 ELECTION ALGORITHMS

4. 6.1 CLOCK SYNCHRONIZATION 6.1.1 Physical Clocks 6.1.2 Global Positioning System 6.1.3 Clock Synchronization Algorithms

5. problem In a centralized system, time is unambiguous In a distributed system, achieving agreement on time is not trivial e.g. make program

6. 6.1.1 Physical Clocks Clock tick –A Counter and a holding register –Each oscillation of the crystal decrements the counter by one –When the counter gets to zero, an interrupt is generated and the counter is reloaded from the holding register –Each interrupt is called one clock tick With a single computer and a single clock, it does not matter much if this clock is off by a small amount –All that really matters are the relative times

7. Time clock skew –This difference in time values of different machines Seconds –solar second (mean) –atomic second TAI –UTC BIR solves the problem by introducing leap seconds whenever the discrepancy between TAI and solar time grows to 800 msec. UTC is the basis of all modern civil timekeeping

8. Leap second

9. Since 1 sec is a noticeable interval for a computer, an operating system that needs to keep accurate time over a period of years must have special software to account for leap seconds as they are announced

10. 6.1.2 Global Positioning System A satellite continuously broadcasts its position and time stamps each message with its local time

11. determining positions two important real-world facts –It takes a while before data on a satellite's position reaches the recerver –The receiver's clock is generally not in synch with that of a satellite Errors –leap seconds –atomic clocks in the satellites are not always in perfect –the position of a satellite is not known precisely –the receiver's clock has a finite accuracy –the signal propagationspeed is not constant –the earth is not a perfect sphere

12. 6.1.3 Clock Synchronization Algorithms the goal is to keep all the machines together as well as possible Each machine –timer that causes an interrupt H times a second –software clock –All C(U) = t, in a perfact world resynchronization If two clocks are drifting from UTC in the opposite direction, at a time dt after they were synchronized, they may be as much as 2p apart

14. Network time protocol The server can accurately provide the current time Offset of time –A send a request to B, timestamped with value T1 –B record the time of receipt T2 –B returns a response timestamped with value T 3, and piggybacking the previously recorded value T2 –A records the time of the response's arrival T4 –assumeT2-T1 =T4-T3, A can estimate its offset relative to B as theta, theta =((T2-T1)+(T3-T4))/2 Adjust time –Gradually –Time interrupt: time unit +/-

16. NTP--strata NTP divides servers into strata stratum 0 –the atomic clock itself stratum-1 –A server with a reference clock such as a WWV receiver or an atomic clock When A contacts B, it will only adjust its time if its own stratum level is higher than that of B

17. The Berkeley Algorithm In NTP, the time server is passive. Berkeley Algorithm –polling every machine –computes an average time –all the other machines to set their clocks to the new time no machine has a WWV receiver it is sufficient that all machines agree on the same time

18. The Berkeley Algorithm

19. Clock Synchronization in Wireless Networks in a sensor network the time to propagate a signal to other nodes is roughly constant –no multi-hop routing is assumed Reference broadcast synchronization (RBS) is a clock synchronization protocol –does not assume that there is a single node with an accurate time –it aims at merely internally synchronizing the clocks

20. The idea underlying RBS when a node broadcasts a message m each node p simply records the time Tp,m that it received m. two nodes p and q can exchange each other's delivery times in order to estimate their mutual, relative offset

21. Improvement Unfortunately, clocks can drift apart The effect is that simply computing the average offset as done above will not work

22. 6.2 LOGICAL CLOCKS 6.2.1 Lamport's Logical Clocks –it may be sufficient that every node agrees on a current time –Example: make 6.2.2 Vector Clocks –with Lamport clocks, nothing can be said about C(a) < C(b), then this does not necessarily imply that a indeed happened before b

23. happens-before relation If a and b are events in the same process, and a occurs before b, then a ~ b is true. If a is the event of a message being sent by one process, and b is the event of the message being received by another process, then a ~ b is also true Happens-before is a transitive relation, so if a ~ band b ~ c, then a ~ c.

24. concurrent Iftwo events, x and y, happen in different processes that do not exchange messages (not even indirectly via third parties), then x ~ y is not true, but neither is y ~ x. These events are said to be concurrent, which simply means that nothing can be said (or need be said) about when the events happened or which event happened first

25. Lamport's algorithm corrects clocks

26. explanation Lamport's solution follows directly from the happens-before relation –Since m 3 left at 60, it must arrive at 61 or later When a message arrives and the receiver's clock shows a value prior to the time the message was sent, the receiver fast forwards its clock to be one more than the sending time

27. The positioning of logical clocks

28. Lamport's logical clocks each process Pi maintains a local counter G –executing an event –delivering a message to an application –some other internal event –Pi executes G = G + 1 When process Pi sends a message m to Pj, it sets timestamp ts (m) equal to G Upon the receipt of a message m, process Pj adjusts its own local counter as max{G, ts (m) }, after which it then executes the first step and delivers the message to the application

29. supplement In some situations, an additional requirement is desirable: no two events ever occur at exactly the same time. we can attach the number of the process in which the event occurs to the low-order end of the time, separated by a decimal point. For example, an event at time 40 at process Pi will be timestamped with 40.i.

30. Totally Ordered Multicasting Example

31. the same order The problem that we are faced with is that the two update operations should have been performed in the same order at each copy Although it makes a difference to execute in the two orders, the order is followed is not important from a consistency point of view The important issue is that both copies should be exactly the same.

32. totally-ordered multicast a multicast operation by which all messages are delivered in the same order to each receiver. Lamport's logical clocks can be used to implement totally-ordered multi casts in a completely distributed fashion

33. solution When a process receives a message, it is put into a local queue, ordered according to its timestamp. The receiver multicasts an acknowledgment to the other processes. Note that if we follow Lamport's algorithm for adjusting local clocks, the timestamp of the received message is lower than the timestamp of the acknowledgment. The interesting aspect of this approach is that all processes will eventually have the same copy of the local queue (provided no messages are removed).

34. 6.3 MUTUAL EXCLUSION 6.3.1 Overview 6.3.2 A Centralized Algorithm 6.3.3 A Decentralized Algorithm 6.3.4 A Distributed Algorithm 6.3.5 A Token Ring Algorithm 6.3.6 A Comparison of the Four Algorithms

35. 6.4 GLOBAL POSITIONING OF NODES

36. 6.5 ELECTION ALGORITHMS 6.5.1 Traditional Election Algorithms 6.5.2 Elections in Wireless Environments 6.5.3 Elections in Large-Scale Systems