Distributed Systems (5DV147)

Transcription

1 Distributed Systems (5DV147) Mutual Exclusion and Elections Fall

2 Processes often need to coordinate their actions Which rocess gets to access a shared resource? Has the master crashed? Elect a new one! 2

3 Distributed mutual exclusion 3

4 Motivation Is needed to coordinate access to a shared resource Concurrent access to a shared resource is serialized but the solution need to be based on message assing Three basic aroaches Token-based Permission-based Quorum-based 4

5 Assumtions The system is asynchronous, rocess do not fail, and message delivery is reliable N rocesses i (i=1, 2,, N ) that do not share variables i access shared resources in a critical section i s are well behaved, finite time on the critical section enter() resourceaccesses() exit() Alication level rotocol for executing a critical section 5

6 Fairness Absence of starvation Order in which rocess enter critical section No global clocks Haened-before ordering: it is not ossible for a rocess to enter the critical section more than once while another waits to enter. 6

7 Essential requirements safety: at most 1 rocess may enter the critical section at a time liveness: requests to enter and exit the critical section eventually succeed Freedom of deadlock and starvation ordering: if a request to enter the critical section haened-before another, then access is granted according to that order 7

8 Metrics for evaluation of algorithms Bandwidth consumed Entry and exit oerations Client delay Throughut of the system Synchronization delay, one rocess exit and another one enters the critical section 8

9 MUTEX: Algorithms Central Server Send request to server, oldest rocess in queue gets access (a token), return token when done No rocess has token rely (enter) immediately Otherwise queue request 1 Queue of requests 1. Request token Server Grant token 2. Release token 4 Oldest rocess in the queue gets token after released 2 3 Figure adated from Instructor s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concets and Design Edn. 5 Pearson Education 2012 Figure

10 Proerties MUTEX: Algorithms Safety? Yes! Liveness? Yes (as long as server does not crash) ordering? No! Why not? Performance Entering : 2 messages (request + grant) Exiting : 1 message Performance bottleneck Single oint of failure Synch and client delay : 2 messages (release + grant) 10

11 MUTEX: Algorithms Ring-based Token is assed around a ring of rocesses Want access? Wait until token comes, and claim it (then ass the token along) n Can t use the same token twice Can t estimate when a rocess will see a token 4 Token Recovering from a rocess crash Receit acknowledgments Figure adated from Instructor s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concets and Design Edn. 5 Pearson Education 2012 Figure

12 Proerties MUTEX: Algorithms Safety? Liveness? Yes (assuming no crashes) ordering? Not even close! Performance Continuously uses network bandwidth Client delay : between 0 N messages Exiting : 1 message Synchronization delay : between 1 N messages 12

13 Ricart and Agrawala MUTEX: Algorithms Distributed algorithm, no central coordinator Use Lamort timestams to order requests Multicast a request message Enter critical section only when all other rocesses have given ermission Processes work cooeratively to rovide access in a fair order Use multicast rimitive or each rocess needs a grou membershi list 13

14 Details MUTEX: Algorithms Each rocess Has unique rocess ID Has communication channels to the other rocesses Maintains a logical (Lamort) clock Has state {wanted, held, released} Requests are multicasted to grou (rocess ID and clock value) <id, value> Lowest clock value gets access first Equal values? Check rocess ID! 14

15 On initialization state := RELEASED; To enter the section state := WANTED; Multicast request to all rocesses; request rocessing deferred here T := request s timestam; Wait until (number of relies received = (N 1)); state := HELD; MUTEX: Algorithms On receit of a request <T i, i > at j (i j) if (state = HELD or (state = WANTED and (T, j ) < (T i, i ))) then queue request from i without relying; else rely immediately to i ; end if To exit the critical section state := RELEASED; rely to any queued requests; RELEASED or earlier timestam Have access or want access and <id, value> is lower than incoming request? Figure adated from Instructor s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concets and Design Edn. 5 Pearson Education 2012 Figure

16 Examle MUTEX: Algorithms Rely Rely 34 Rely 2 34 Figure adated from Instructor s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concets and Design Edn. 5 Pearson Education 2012 Figure

17 Proerties MUTEX: Algorithms Safety? Liveness? ordering? Yes! but every node is a oint of failure Performance Entering : 2(N-1) messages (n-1) multicast request + (n-1) relies Client delay : 1 round-tri Synchronization delay : 1 message transmission Imrove erformance If rocess wants to re-enter critical section, and no new requests have been made, just do it! Grant access using simle majority 17

18 Maekawa s voting Otimization: only ask subset of rocesses for entry Key is how to build the subsets At least one common member in any two voting sets Each rocess has a voting set of the same size Each rocess is in as many voting sets as the number of rocesses in a voting set Works as long as subsets overla Use matrix of n by n and voting sets are the union of rows and columns Vote only in one election at a time! MUTEX: Algorithms 18

19 Details On initialization state := RELEASED; voted := FALSE; For i to enter the critical section state := WANTED; Multicast request to all rocesses in V i ; Wait until (number of relies received = K); state := HELD; On receit of a request from i at j if (state = HELD or voted = TRUE) then queue request from i without relying; else send rely to i ; voted := TRUE; end if For i to exit the critical section state := RELEASED; Multicast release to all rocesses in V i ; MUTEX: Algorithms On receit of a release from i at j if (queue of requests is non-emty) then remove head of queue from k, say; send rely to k ; voted := TRUE; else voted := FALSE; end if Safety? Yes Liveness? ordering? No, deadlocks can haen! V 1 ={ 1, 2 }, V 2 ={ 2, 3 }, V 3 ={ 3, 1 } 19

20 Comarison of Mutex algorithms MUTEX: Algorithms Central server: simle and error-rone! but otherwise good erformance!! Ring-based algorithm: also simle, but not single oint of failure Ricart and Agrawala: comletely distributed and decentralized multicast request, access when all have relied (ordered using logical clocks) Maekawa's voting algorithm: ask only a subset for access: works if subsets are overlaing 20

21 more comarison MUTEX: Algorithms Message loss? Crashing rocesses? None of the algorithms handle this Ring? No! others? deends (central- not server nor holding or having requested token, Maekawa s only if crashed rocess is not in voting set) 21

22 Summary Summary MUTEX Algorithms Control access to shared resources Algorithms central server ring-based Ricart and Agrawala Maekawa's voting algorithm 22

23 Election algorithms 23

24 Motivation Election How to choose a rocess to lay a articular role in the system Start with all rocess in same state One rocess will reach state leader Other rocess will reach state lost 24

25 Details Election Any rocess can call an election but can only call one election at a time Each rocess has the same local algorithm The elected rocess is the one with the largest identifier, identifiers should be unique and totally ordered The election must always roduce a unique winner 25

26 Essential requirements Election safety: A articiant has elected i = P, where P is chosen as the non-crashed rocess with the highest identifier = False or elected i liveness: All rocesses articiate and eventually set elected i to not =False or crash 26

27 Ring-based algorithm Election algorithms Goal is to elect a single rocess the coordinator rocess with the largest identifier During election, ass max(own ID, incoming ID) to next rocess If a rocess receives own ID, it must have been highest and may send that it has been elected 27

28 Details 3 17 Election algorithms Safety? Liveness? Yes! Tolerates no failures (limited use) The election was started by rocess 17 The highest rocess identifier encountered so far is 24. Particiant rocesses are shown in a darker color Worst case, N-1 messages until reaching eer with largest identifier + N messages to comlete another circuit + N messages advertising the election 3N-1 messages Figure adated from Instructor s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concets and Design Edn. 5 Pearson Education 2012 Figure

29 Bully algorithm Election algorithms Requires: Synchronous system All rocesses know of each other (which ones have higher ids) Reliable failure detectors Reliable message delivery Allows Crashing rocesses 29

30 Details Process P discovers that leader has crashed P sends an Election message to all rocesses with higher numbers If no one resonds, P wins the election and becomes coordinator If one of the higher us answers, it takes over, P s job is done Uon receiving an Election message, the receiving rocess resond to sender and initiates an election 30

31 Examle Election algorithms The election of coordinator 2, after the failure of 4 and then 3 election Safety? Not if rocess IDs can be reused! Liveness? Yes (if message delivery is reliable) Stage 1 Stage 2 Stage 3 1 answer timeout election answer 2 answer election 3 election election C 4 C Eventually.... Stage 4 1 coordinator Figure adated from Instructor s Guide for Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concets and Design Edn. 5 Pearson Education 2012 Figure 15.8 C

32 Summary Summary election algorithms Election algorithms Seems like a simle roblem, but non-trivial solutions are... non-trivial Want to read more about non-trivial election algorithms? htt:// 32

33 Next Lecture Grou communication 33