Transcript - Way2MCA
Synchronization
Synchronization
Difficult to implement synchronization in distributed environment – Memory is not shared – Clock is not shared – Decisions are usually based on local information – Centralized solutions undesirable (single point of failure, performance bottleneck) Synchronization mechanisms used to facilitate competitive sharing – Clock synchronization – Event ordering – Mutual exclusion – Deadlock – Election algorithms cooperative or
Clock synchronization
Timer mechanism used to keep track of current time, accounting purposes, measure duration of distributed activities that starts on one node and terminates on another node etc.
Computer Clocks – A quartz crystal that oscillates at fixed frequency.
– A counter register whose value is decremented by one for every oscillation of quartz crystal.
– A constant register to reinitialize counter register when its value becomes zero & an interrupt is generated.
Drifting of Clocks
Differences in crystals result in difference in the rate at which two clocks run.
Due to difference accumulated over time computer clocks drifts from real time clock used for their initial setting.
If ρ is maximum drift rate allowable, a clock is said to be non-faulty if : 1 ρ ≤ dc/dt ≤ 1+ ρ The nodes of a distributed system must periodically resynchronize their local clocks to maintain a global time base across the entire system.
Clock Drift
Synchronization techniques – External Synchronization • Synchronization with real time (external) clocks • Synchronized to UTC (Coordinated Universal Time) – Mutual (Internal) Synchronization • For consistent view of time across all nodes of the system External Synchronization ensures internal synch.
Issues in Clock synchronization
The difference in time values of two clocks is called clock skew .
Set of clocks are said to be synchronized if the clock skew of any two is less than δ (Specified constant).
A node can obtain only an approximate view of its clock skew with respect to other nodes’ clocks in the system, due to unpredictable communication delays.
Readjustments done for fast/ slow running clocks If time of a fast clock readjusted to actual all at once, might result in running time backward for that clock.
Use intelligent interrupt routine .
Question: A distributed system has 3 nodes n1, n2, n3 each having its own clock. The clock at nodes n1, n2, n3 tick 495, 500 & 505 times per millisecond. The system uses external clock synchronization mechanism in which all nodes receive real time every 20 seconds from an external file source & readjust their clocks. What is the maximum clock skew that will occur in this system?
Answer: n1 = .495 s, n2= .500 s, n3 = .505 s Maximum skew in 1 sec between n1 & n3 = (.505-.495) = .010 sec Thus, skew in 20 sec = .010 * 20 = .2 sec
Synchronization algorithms
Centralized Algorithms Distributed Algorithms Active Time Server Passive Time Server Global Averaging Local Averaging
Centralized Algorithms
Keep the clocks of all nodes synchronized with the clock time of the time server node, a real time receiver.
Drawbacks – Single point of failure – Poor scalability
Passive time server centralized algorithm Active time server centralized algorithm
Passive Time Server Centralized
Each node periodically sends message the time server (“time=?”) to Server responds by sending (“time = T”) After receiving client adjusts time to – T+ (T 1 -T 0 )/2 (T 0 – time when client sent request, T 1 client when received reply, thus - time of message propagation time one way is ((T 1 -T 0 )/2) – T+ (T 1 -T 0 - I)/2 , I is time taken by time server to handle time request message – T+ (average (T 1 -T 0 ))/2
Active Time Server Centralized
Time server node periodically broadcasts clock time (“time=T”) Time of propagation (T a ) from server to client is known to all clients Client adjusts time to T + T a Drawbacks – Not fault tolerant in case message reaches too late at a node, its clock will be adjusted to wrong value – Requires broadcast facility Drawbacks overcome by Berkeley algorithm
Berkeley Algorithm
Used for internal clock synchronization of a group Time server periodically sends a message computers in the group (“time=?”) to all Each computer in the group sends its clock value to the server Server has prior knowledge of propagation time from node to server Time server readjusts the clock values of the reply messages using propagation time & then takes fault tolerant average The time server readjusts its own time & (positive or negative) to each node sends the adjustment
Distributed Algorithms
All nodes are equipped with real time receiver so that each node’s clock is independently synchronized with real time External synchronization also results in internal synchronization.
Internal synchronization performed for better results Global averaging distributed algorithms Localized averaging distributed algorithms
Global Averaging Distributed Algorithms
Local time with “resync” message is broadcasted from each node at beginning of every fixed length resynchronization interval T 0 +iR, R is system parameter.
All broadcasts do not happen simultaneously due to difference in local clocks.
Broadcasting node waits for time T during which it messages by other nodes collects “resync” & records time of receipt according to its own clock.
At the end of waiting time, it estimates the skew of its clock with respect to other nodes on the basis of times at which it received “resync” messages.
Calculate fault tolerant average of estimated skews & uses it to correct its own local clock before restart of next “resync” interval
Localized Averaging Distributed Algorithms
Nodes of a DS are logically arranged in some kind of pattern, such as ring or a grid.
Periodically, its neighbors each node exchanges its clock time with in the ring, grid etc.
It then sets its clock time to the average of its own clock time and the clock time of its neighbors.
Event Ordering
Observations by Lamport – If two processes do not interact, it is to keep their clocks synchronized.
not necessary – All processes need not agree on exactly what time it is, rather they agree on the order in which events occur.
– Events can be • Procedure invocation • Instruction execution • Message exchange (Send/ Receive) – Defined relation ordering of events.
happened before , for partial
Happened Before Relation
Happened before relation ( casual ordering) – If a and b are occurs before b events in the same process , and then a → b is true.
a – If a is the event of a message being sent by one process, and received b is the event of the message being by another process, then a → b is also true.
– If a → b and b → c, then a → c (transitive).
Irreflexive, a → a not true Concurrent Events (a||b) if neither a - events a and b are concurrent → b nor b → a is true.
Space-time Diagram for three processes
e 32 e 13 e 24 e 23 e 22 e 12 e 31 e 11 e 21 e 10 e 20 e 30 Process P1 Process P2 Process P3 Casually ordered events => (e 10 →e 11 ), (e 20 →e 24 ), (e 21 →e 23 ), (e 21 →e 13 ), (e 30 →e 24 ), (e 11 →e 32 ) Concurrent events => (e 12 , e 20 ), (e 21 ,e 30 ),(e 10 ,e 30 ),(e 12 ,e 32 ),(e 13 ,e 22 )
Question List all pairs of concurrent events according to happened before relation.
e 2 e 1 e 4 e 3 Process P1 e 9 e 8 e 7 e 6 e 5 Process P2
Logical Clocks
Need globally synchronized clocks to determine a → b – Rather use Logical clock concept • Associate timestamp with every event • Timestamps assigned to events by logical clocks must follow clock condition : if a → b, then C(a) < C(b) Conditions to follow to satisfy clock condition – If a occurs before b in process P i – If a is the sending of a message receipt by process P i of that message by process P j then C i and (a) The implementation rules of lamport’s algorithm – IR1 : Each process P i two events increments C i between any – IR2 : If event a is the sending of message m by process P i the message m contains a timestamp T m = C i (a). Upon receiving the message m, a process P j sets C j greater than or equal to its present value but greater than T m All processors have counters acting as logical clocks. Counters initialized to zero & incremented by 1 whenever an event occurs in that process. On sending of a message, the process includes the incremented value of the counter in the message. On receiving the message, counter value incremented by 1 & then checked against counter value received with message. – If counter value is less than that of received message, the counter value set to (timestamp in the received message + 1). Ex. e 13 . – If not , the counter value is left as it is. Ex. e 08 C1=8 e 08 C1=7 e 07 C1=6 e 06 C1=5 e 05 C1=4 e 04 C1=3 C1=2 C1=1 C1=0 e 03 e 02 e 01 Process 1 e 14 C2=6 e 13 C2= 3 5 e 12 C2=2 e 11 C2=1 Process 2 C2=0 Example: Three processes that run on different machines, each with its own clock, running at its own speed. When the clock has ticked 6 times in process 0, it has ticked 8 times in process 1 and 10 times in process 2. Each clock runs at a constant rate, but the rates are different due to differences in the crystals. At time 6: process 0 sends message A to process 1. The clock in process 1 reads 16 when it arrives. If the message carries the starting time 6 in it, process 1 will conclude that it took 10 ticks to make the journey. According to this reasoning, message B from 1 to 2 takes 16 (40 – 24) ticks, again a plausible value. Message from 2 to 1 leaves at 60 and arrives at 56. Impossible! Message D from 1 to leaves at 64 and arrives at 54. Impossible! Lamport's solution: Each message carries the sending time, according to the sender's clock. 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. Since C left at 60, it must arrive at 61 or later. On the right we see that C now arrives at 61. Similarly, D arrives at 70. No two events ever occur at exactly the same time. Say events a & b occur in processes P 1 & P 2 respectively, at time 100 according to their clocks. Process identity numbers are used to create their ordering. Timestamp of a is 100.001 (process id of P 1 is 001) & of b is 100.002 (process id of P 2 is 002) Exclusive access to shared resources achieved by critical sections & mutual exclusion . Conditions to be satisfied by mutual exclusion: – Mutual exclusion - Given a shared resource accessed by multiple concurrent processes, at any time only one to another process. process should access the resource. A process that has been granted the resource must release it before it can be granted – No starvation – If every process that is granted resource eventually releases it, every request will be eventually granted. Coordinator coordinates entry to critical section Allows only one process to enter critical section. Ensures no starvation as uses first come, first served policy. Simple implementation 3 messages per critical section release – request, reply, Single point of failure & performance bottleneck. P2 P1 5 Release 2 Reply 1 Request P c 9 Release 8 Reply 4 Request P3 Status of request queue Initial state P2 Status after 3 P3 P2 Status after 4 P3 Status after 5 Status after 7 Ricart & Agrawala’s Algorithm When a process wants to enter the CS, it sends a request message to all other processes, and when it receives reply from all processes, then only it is allowed to enter the CS. The request message contains following information: – Process identifier – Name of CS – Unique time stamp request message generated by process for The decision whether receiving process replies immediately to a request message or defers its reply is based on three cases: – If receiver process is in its critical section, then it defers its reply – If receiver process does not want to enter its critical section, then it immediately sends a reply. – If receiver process itself is waiting to enter critical section, then it compares its own request timestamp with the timestamp in request message • If its own request timestamp is greater than timestamp in request message, then it sends a reply immediately. • Otherwise, the reply is deferred P1 TS=6 TS=4 P2 P4 Already in CS a P3 P1 OK OK P2 Queue P1 Defer sending a reply to P1 OK Queue P4 P2 P1 Defer sending reply to P1 and p2 b P3 P1 OK Exits CS P4 OK c P2 Queue P1 Enters CS P3 Enters CS P1 OK Exits CS P2 P4 P3 d Guarantees mutual exclusion as a process enters critical section only after getting permission from all other processes. Guarantees no starvation as according to timestamp ordering. scheduling done If there are n processes, 2(n-1) messages (n-1 request & n-1 reply) are required per critical section entry. N points of failure in a system of n processes . All requesting processes have to wait indefinitely if one process fails. Send deferring reply & “permission denied” instead of “ok” when permission granted. The processes need to know the identity of all other processes in the system , which makes the dynamic addition and removal of processes more complex. Suitable for groups whose member processes are fixed. Process enters critical section after exchange of 2(n 1) messages. Waiting time for exchanging 2(n-1) messages can be quite large. group of co-operating processes. Suitable for small Processes organized in logical ring Single token circulated among processes in system Token holder allowed to enter critical section On receiving token, process: – If it wants to enter CS, keeps token & enters CS. It passes token to its neighbor on leaving CS. A process can enter only one CS when it receives the token. – If it does not want to enter CS, it passes token to its neighbor. Mutual exclusion achieved as single token present. No starvation as ring is unidirectional & a process is permitted to enter only one CS at a time. Number of messages per CS vary from 1 to unbounded value. Wait time to enter a CS varies from 0 to n-1 messages. Two types of failure can occur: Process failure – Requires detection of reconfiguration of logical ring failed process & dynamic – Process receiving token sends back neighbor acknowledgement to – When a process detects failure of neighbor, it removes failed process by skipping it & passing token to process after it. Lost token – Must have mechanism to detect & regenerate token – Designate process as “who has token” monitor . Monitor periodically circulates – Owner of token writes its process identifier in message & passes on. – On receipt of message, monitor checks process identifier field. If empty generate new token & passes it. – Multiple monitors can be used. Used for electing a coordinator process from among the currently running processes in such a manner that at any instance of time there is a single coordinator for all processes in the system. Election algorithms based on assumptions: – Each process has unique priority number . – Highest priority process among currently active processes is elected as the coordinator. – On recovery, a failed process can rejoin active processes . the set of • Assumes that every process knows priority of every other process in the system. • When a process P j coordinator within a fixed time period, it assumes that the coordinator has failed. does not receive reply of request from • P j initiates election by sending message to the processes having priority higher than itself • If P j does not receive any reply, it takes up job of the coordinator & sends message to all processes with lower priority about it being new coordinator. • If P j receives any reply, process with higher priority is alive. Processes with higher priority now take over election activity. • The highest priority process (that does not receive any reply) becomes new coordinator. A failed process initiates election on recovery. If process with highest priority recovers from failure, it simply sends a coordinator message to all other processes submission. & bullies current coordinator into In a system of n processes when process with lowest priority detects coordinator’s failure, n-2 elections are performed. O(n 2 ) messages If process just below coordinator detects its failure, it elects itself as coordinator & sends n-2 messages . On process failure recovery, depending upon process priority O(n 2 ) messages in worst case, n-1 messages in best case are required. Processes are ordered – Each process knows its successor – No token involved Any process noticing that the coordinator is not responding sends an election message with its priority number to its next live successor Receiving process adds its priority number to the message and passes it along When message gets back to election initiator, it elects the process having the highest priority number as the coordinator and changes message to coordinator & circulates to all members Coordinator is process with highest priority number When failed process recovers it does not initiate election. It simply circulates the inquiry message in the ring to find current coordinator. If more than coordinator? one process detects a crashed – More than one election will be produced but all messages will contain the same information (member process numbers, order of members). Same coordinator is chosen (highest number). Irrespective of which process detects error, election always require 2(n-1) messages . More efficient & easier to implementImplementation of Logical Clock using Counters
Implementation of Logical Clock
Implementation of Logical Clock using Physical Clocks
Total Ordering
Mutual Exclusion
Centralized Approach
Centralized Approach
Distributed Approach
Distributed Approach
Drawbacks
Token Passing Approach
Election Algorithm
Bully Algorithm
Ring Algorithm