1 / 123

Ch10 Synchronization and Election

Ch10 Synchronization and Election. Introduction. We shall be concerned with basic distributed algorithms for Synchronization (basic idea ordering) Required for consistent execution e.g. Maintenance of replicated data Consistency of distributed shared memory

zamir
Download Presentation

Ch10 Synchronization and Election

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Ch10Synchronization and Election

  2. Introduction • We shall be concerned with basic distributed algorithms for • Synchronization (basic idea ordering) • Required for consistent execution • e.g. Maintenance of replicated data • Consistency of distributed shared memory • Election (agreeing on who is the coordinator) • Required wherever there is a coordinator • If the current coordinator fails, one must reelect a new • coordinator • e.g. Replicated data management, • Atomic commit, recovery management, etc.

  3. Introduction (cont.) Communication scenarios: One way: an application process sends messages and expects no reply e.g. Broadcast Client/server: a client sends a service request then waits for a reply from the server Peer: a symmetrical two ways communication

  4. How coordination is achieved depends on which communication scenario is assumed One way communication: applications using one way communication usually don’t need synchronization Client/server communication: if the coordination is required among the clients, it is handled by the server and there is no explicit interaction among processes Peer: processes need to exchange information to reach some conclusion about the system or some agreement among the cooperating processes. There is no centralized controller Distributed Mutual Exclusion

  5. Distributed Mutual Exclusion • Mutual Exclusion Problem: • Ensures that concurrent processes make a serialized access to • shared resource or data (called Critical Section, CS for short) • e.g. updating a database; • sending a control command to a shared I/O device • Distributed Mutual Exclusion Problem: • Achieve the mutual exclusion (fairness, progress properties) • assuming only peer communication • Assumptions: • We assume that no failures occur during the execution • Each node can communicate with every other node

  6. Distributed Mutual Exclusion Approaches to achieve distributed mutual exclusion: Contention-based approach processes compete for the right to use the shared resource by using a request resolution criteria Criteria: time of request;priorities of requesters; voting Controlled-based approach A logical token representing the access right to the shared object is passed in a regulated fashion among the competing processes. A process holding the token can enter the CS

  7. Distributed Mutual Exclusion Design goal : Find: Entry Protocol and Exit Protocol Entry protocol <Critical Section> Exit protocol

  8. Outline Distributed Mutual Exclusion Timestamp Algorithms Voting Use of token on logical structures Path Compression Election The bully Algorithm The invitation Algorithm

  9. Timestamp Algorithms:(Lamport’s algo. modified) Idea: A processor p requests the CS by sending Request(t) to every other processor (t=Lamport’s time when the processor p requests the CS) A processor q replies by sending Reply(t’) to p where: t’= null if q is not competing or the request of q is later t’= the time when q made the request, if q’s request was earlier Each requesting processor p maintains a queue my_Q such that: my_Q[j] is the Lamport time when processor j made its request; my_Q is arranged in the ascending order Distributed Mutual Exclusion

  10. Lamport’s algo. modified: (intuition) Distributed Mutual Exclusion p requests CS every other sends Reply(ti) p receives a Release Request(t) Reply(t1) Request(t) Reply(t2) Release p p q p q my_Q:=empty p waits until it has received a Reply from every other On receipt of Reply(t2) from q, p inserts q in my_Q only if t2 null p removes q from my_Q if q is in my_Q p exits CS When all other processors have replied, p inserts itself in my_Q. p can enter CS only if p has received a Reply(t’) from every other processor and head(my_Q)=p Release Release p q

  11. The modified Lamport’s algorithm illustrated Distributed Mutual Exclusion p1 p2 p3 p4 RQ(t) = timestamped Request my_Q:=[] RQ(t) RQ(t) RQ(t) RY(t) = timestamped Reply RY(null) RY(t4) RY(t3) t3<t my_Q=[] t4<t3<t CS my_Q=[p3] Release my_Q=[p4,p3,p1] Release Release my_Q=[p3,p1] CS Release Release Release my_Q=[p1] CS Release my_Q:=[] Release Release

  12. Distributed Mutual Exclusion Timestamp Algorithms: (Lamport’s algorithm modified) The algorithm consists of three parts: Request_CS(), Monitor_CS() and Release_CS() Request_CS() my_PQ := ; /* my priority queue */ is_requesting := True; reply_needed := M-1; m:= Request ; /* the Request message */ my_timestamp := my_current_Lamport_time; m.timestamp := my_timestamp; /* request’s time */ foreach processor k  self do send(k,m); waituntil reply_needed = 0 and head(my_PQ) = self <use CS>

  13. Distributed Mutual Exclusion Release_CS() for each processor k  self do m:= Release; send(k,m) is_requesting := False; my_PQ := 

  14. Distributed Mutual Exclusion Timestamp Algorithms: (Lamport’s algo. modified Cont.) CS_Monitor() waitfor Reply, Request, Release fromany processor on the receipt of Reply from p do if Reply.timestamp  null then insert p in my_PQ; reply_needed := reply_needed -1 if reply_needed = 0 then insert self in my_PQ end end

  15. Distributed Mutual Exclusion Timestamp Algorithms:(Lamport’algo. CS_Monitor() cont.) on the receipt of Request from p do m:= Reply; if not (is_requesting) or (my_timestamp > Request.timestamp) then m.timestamp:= null else m.timestamp:= my_timestamp; send (p, m) end on the receipt of Release from p do if is_requesting then remove p from my_PQ end end

  16. Analysis of the modified Lamport’s algorithm Distributed Mutual Exclusion p q p sends a Request message to every other: (M-1) Request every other processor q sends a Reply to p: (M-1) Reply p might be at the end of its priority queue: (M-1) Release Thus 3(M-1) messages might be sent in order for p to enter its CS In addition, each processor has to manage (need of insert on) a priority queue Request Reply Release Can we do better?

  17. Ricart and Agrawala’s algorithm: does better The idea (Avoid Release messages, use of silence!): Request: When a processor p wants to enter the CS, p sends Request(t) to every other processor then p waits until it receives a Reply message from every other processor Reply: When a processor q receives a Request(t) message from p, if (q is not requesting the CS ) or (q’s request is later than p’s) then q sends Reply to p Otherwise (using the CS or q’s request is earlier), q defers the sending of a Reply message to p until Exit Exit: When a processor exits the CS, it sends all deferred Reply messages Distributed Mutual Exclusion

  18. Ricart and Agrawala’s algorithm: Variables used: timestamp current_time /* the current Lamport time */ timestamp my_timestamp /* timestamp of your request */ integer reply_count /* number of permissions you still need to collect before entering your CS */ boolean is_requesting /* True iff you are requesting or you are in your CS */ boolean reply_deferred[M] /* reply_deferred[j] is True iff you have deferred the sending of a Reply message to processor j */ Distributed Mutual Exclusion

  19. Ricart and Agrawala’s algorithm: (The algorithm) Distributed Mutual Exclusion Request_CS() my_timestamp := current_timestamp; is_requesting := True; reply_pending := M-1; m:=Request; m.timestamp := my_timestamp; foreach j  self do send(j, m) waituntil reply_pending = 0 Release_CS() is_requesting := False; foreach j  self such that reply_deferred[j]=True do send(j,Reply); reply_deferred[j] := False

  20. Ricart and Agrawala’s algorithm: (The algorithm, cont.) Distributed Mutual Exclusion Monitor_CS() waitforRequestorReplyfromany processor on receipt of Requestfrom p do if not (is_requesting) or my_timestamp > Request.timestamp then send(p, Reply) else reply_deferred[p] := True end on receipt of Reply from p do reply_pending := reply_pending - 1 end end

  21. Example 8 RQ,8 6 RQ,8 9 time 10 7 RQ,6 OK,9 10 RQ,6 11 11 12 OK,12 RQ,10 13 12 RQ,10 14 OK,12 13 15 CS 16 OK,16 17 OK,16 17 19 OK,18

  22. Ricart and Agrawala’s algorithm: (Analysis) • No priority queue • (M-1) Request messages • (M-1) Reply messages • Thus 2(M-1) messages to enter a CS. • Properties: • Use of symmetric information • priority queue: when a processor enters the CS it knows that • no other processor can enter the CS • deferred Reply: when a processor receives a Reply from every • other processor, it knows that no other processor has the same • information Distributed Mutual Exclusion

  23. Outline Distributed Mutual Exclusion Timestamp Algorithms Voting Use of token on logical structures Path Compression Election The bully Algorithm The invitation Algorithm

  24. Voting-based Algorithms Processors that want to enter the CS compete for votes. Idea: Each processor has a unique vote that it can give to at most one processor (itself or some other processor) Whenever a processor p wants to enter the CS, p asks every other processor for its vote When p knows that it has received more votes than any other processor then p can enter the CS Otherwise, p must wait until the processor that is in the CS exits, releasing its vote for other contenders Distributed Mutual Exclusion

  25. Distributed Mutual Exclusion Voting-based Algorithms (a naïve algorithm) Naïve_Voting_Enter_CS() Sends a vote request to all of the processors when you receive at least (M+1)/2 votes, enter the CS Naïve_Voting_Exit_CS() sends a Release message to all of the processors Problems:a deadlock can occur: three competing processors might each get one-third of the votes No significant advantage over timestamp-based algorithm O(M) messages are required.

  26. Distributed Mutual Exclusion Voting-based algorithms: quorums and coteries Aim: Reduce the message complexity by reducing the number of votes required to enter the CS Avoid the possibility of deadlock Idea Every processor p has a voting district Sp (also called, quorum) The set {S1,…,SM} is called a coterie It is assumed that for each processor p, Sp is fixed Whenever a processor p wants to enter the CS, processor p requests the votes of only all the processors in Sp To enter the CS, p must acquire the votes of all processors in Sp

  27. Voting-based algorithms:(voting districts organization) To ensure mutual exclusion the intersection rule must holds: Si Sj   for each 1 i, j  M Fairness among quorums 1) | Si | = K for each i in {1,…,M} and 2) every processor is in D voting districts How small can we make K and D and still preserve the intersection and the fairness properties ? Maekawa’s solution: M=(K-1) K +1 i.e. K=O( M) easier if we know that M=n2 Distributed Mutual Exclusion

  28. Voting-based algorithms:(quorums illustrated) Assume M=n2and label the processors (i,j) for 1  i,j  n Distributed Mutual Exclusion 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

  29. Voting-based algorithms:(quorums illustrated) Assume M=n2and label the processors (i,j) for 1  i,j  n Distributed Mutual Exclusion 1 2 3 4 5 6 n=6 M=36 7 8 9 10 11 12 13 14 15 16 17 18 S14 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

  30. Distributed Mutual Exclusion Voting-based Algorithms (idea of the general algorithm) Request_CS when processor p wants to enter the CS, p sends a vote request to all of the processors in Sp Reply a processor q in Sp sends YES only if q hasn’t already cast its vote Enter_CS p can enter the CS when it receives Reply from all processors of Sp Exit_CS when p exits the CS, it sends Release to all processors in Sp (enabling the members of its voting district to vote for other candidates) Problem:a deadlock can occur

  31. Voting-based algorithms:(the deadlock illustrated) Distributed Mutual Exclusion 1 2 3 4 5 6 p3 and p23 compete but p5 votes for p3 p21 votes for p23 Neither p3 nor p23 receives all the votes of its voting district: Deadlock 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

  32. Voting-based Algorithms (deadlock avoidance, Idea) Use Lamport timestamps, Voters will prefer to vote for the earliest candidate Request_CS when processor p wants to enter the CS, p sends a timestamped vote REQUEST to all of the processors in Sp Reply When processor q receives p’s REQUEST : q sends its vote to p if q hasn’t already cast its vote If q has already cast its vote for processor r and p’s Request is earlier than r’s Request, then q tries to retrieve its vote from r by sending an INQUIRE message to r Many requests can arrive after you have already sent your vote: a waiting is necessary; Distributed Mutual Exclusion

  33. Distributed Mutual Exclusion Voting-based Algorithms (deadlock avoidance, Idea) Relinquish_Vote when you receive an INQUIRE message from a processor q, relinquishe q’s vote by sending it a RELINQUISH message if you have not already received all the votes of your voting district Old INQUIRE messages can be in the system : timestamp matching is used Release_CS send a RELEASE message to all members of your quorum, take your vote On receipt of a RELEASE message if your waiting queue is not empty, vote for the first processor in that queue Otherwise, keep your vote

  34. Distributed Mutual Exclusion Why the deadlock resolution mechanism presented works? Lamport (systemwide) timestamp imposes a total order so either the candidate with the lowest timestamp eventually gets all of the votes or the candidate with the lowest timestamp is blocked by a candidate that enters the CS.

  35. Distributed Mutual Exclusion Voting-based Algorithms (The algorithm) accounts for the fact that INQUIRE messages are generated asynchronously, so old INQUIRE messages must be handled: timestamp-based matching is used Variables used Sself : the processor voting district LTS : the systemwide (Lamport) timestamp my_TS: the timestamp of the current CS request yes_votes : the number of processor that voted YES have_voted: True iff you have already voted for a candidate (initially False) candidate: the candidate that you voted for candidate_TS: the timestamps of the request of the candidate that you voted for have_inquired: True if you have tried to recall a vote (initially False) WaitingQ: the set of vote requests that you are defering InCS : True iff you are in the CS

  36. Distributed Mutual Exclusion Voting-based Algorithms (The algorithm, cont.) M_Voting_Entry() /* algorithm for requesting the CS */ yes_votes := 0; my_TS := LTS; forevery processor r in Sselfdo send(r, REQUEST; my_TS) while (yes_votes < | Sself |) do wait until a YES or INQUIRE message is received on Yes(sender) do yes_votes := yes_votes + 1 end on INQUIRE(sender, inquire_ts) do if my_TS = inquire_ts then send(sender, RELINQUISH); yes_votes := yes_votes - 1 end end InCS := True /* models the fact that you enter the CS */

  37. Distributed Mutual Exclusion Voting-based Algorithms (The algorithm, cont.) M_Voter() /* algorithm executed by the thread that monitors the CS */ while(1) wait until a REQUEST, RELEASE, or RELINQUISH message is received on REQUEST(sender; request_ts) do if have_voted = False then send(sender, YES); candidate_TS := request_ts; candidate := sender; have_voted := True else add(sender, request_ts) to WaitingQ; if request_ts < candidate_TS and not have_inquired then send(candidate, INQUIRE; candidate_ts) have_inquired := True end

  38. Voting-based Algorithms (M_Vote() cont.) on RELINQUISH(sender) do add (candidate, candidate_TS) to WaitingQ; remove the (s, rts) from WaitingQ such that rts is the minimum send(s, YES); candidate_TS := rts; candidate := s; have_inquired := False end on RELEASE(sender) do if WaitingQ is not empty then remove the (s,rts) from the WaitingQ such that rts is the minimum; send(s, YES); candidate_TS := rts; candidate_TS := s else have_voted := False have_inquired := False end end /* wait */ Distributed Mutual Exclusion

  39. Distributed Mutual Exclusion Voting-based Algorithms (The algorithm, cont.) M_Voting_Exit() /* algorithm for releasing the CS */ forevery processor r in Sselfdo send(r, RELEASE) InCS := False have_voted := False

  40. The general voting algorithm illustrated Distributed Mutual Exclusion 3 A a b c d e f B C 5 7

  41. Outline Distributed Mutual Exclusion Timestamp Algorithms Voting Use of token on logical structures Path Compression Election The bully Algorithm The invitation Algorithm

  42. Distributed Mutual Exclusion Token-based algorithms Idea: A logical token representing the access right to the CS is passed in a regulated manner among the processors The holder of the token is allowed to enter the CS Token-based algorithms often assume a logical structure on the processors Frequently used logical structures: Ring, Spanning tree

  43. Token-based algorithms on Ring topology Distributed Mutual Exclusion The ring is unidirectional every processor knows its successor in the ring When you wants to enter the CS, you wait for the token, take it when it arrives, pass it on to the your successor when you exit the CS If the token arrives and you don’t want it, pass it along immediately Ring topology is attractive because it is simple, deadlock-free and fair: frequently used for access control in Local Area Networks

  44. Token-based algorithms on Ring topology Distributed Mutual Exclusion Problems: Unnecessary network traffic: The token needs to circulate even if no processor wants to enter the CS Consumes processor resources The waiting time can be large A processor can wait for a long time to get the token even if no other processor enters the CS

  45. Token-based algorithms on Tree topology Distributed Mutual Exclusion Underlying goals Reduce the communication complexity Processors explicitly request the token The processor holding the token moves it only if it knows of a pending request Exploit the structure of the tree (no cycle) to avoid deadlock

  46. Token-based algorithms on Tree topology (Raymond’s algorithm) Distributed Mutual Exclusion We can impose a tree structure on the processors as shown below. Two problems: (1) how to let a request navigate to the token (2) token navigation to the next processor to enter the CS

  47. Token-based algorithms on Tree topology (Raymond’s algorithm) Distributed Mutual Exclusion The processor holding the token always resides at the root of a tree Solution: each processor maintains: a pointer to the neighbor (called parent) that is closest to the token; a request queue; the head of which defines the return path 2 [] [] [] 1 3 4 7 15 10 [] 11 12 13 16 5 6 8 9

  48. Token-based algorithms on Tree topology (Raymond’s algorithm) Distributed Mutual Exclusion Idea: Request: insert yourself in your queue, send a request to your parent if you have not yet sent a request to it. On receiving a request: insert the requester in your queue; If you don’t have the token and you haven’t already sent a request to your parent, send a request to your parent (a forward action) If you have the token but you are not using it, remove the first processor of your queue; send the token to that processor On receiving/ releasing the token Remove the first processor (if any) of your queue, send the token to that processor and set your parent pointer to that processor If your queue is not empty (there is another pending request), send a request to the processor you have just sent the token

  49. Raymond’s algorithm illustrated Distributed Mutual Exclusion Initially, the token is at processor 1 processor 4 sends a request to processor 3 2 [] [] [] 1 3 (4) 4 7 15 10 [4] 11 12 13 16 5 6 8 9

  50. Raymond’s algorithm illustrated Distributed Mutual Exclusion processor 3 receives request from processor 4; forwards this request to processor 2 2 [] [4] [] (3) 1 3 4 7 15 10 [4] 11 12 13 16 5 6 8 9

More Related