Recap: Consensus. CSE 486/586 Distributed Systems Mutual Exclusion. Why Mutual Exclusion? Why Mutual Exclusion? Mutexes. Mutual Exclusion C 1

Transcription

1 Reca: Consensus Distributed Systems Mutual Exclusion Steve Ko Comuter Sciences and Engineering University at Buffalo On a synchronous system There s an algorithm that works. On an asynchronous system It s been shown (FLP) that it s imossible to guarantee. Getting around the result Masking faults Using failure detectors Still not erfect Imossibility Result Lemma 1: schedules are commutative Lemma 2: some initial configuration is bivalent Lemma 3: from a bivalent configuration, there is always another bivalent configuration that is reachable. 2 Why Mutual Exclusion? Why Mutual Exclusion? Bank s Servers in the Cloud: Think of two simultaneous deosits of $10,000 into your bank account, each from one ATM connected to a different server. Both ATMs read initial amount of $1000 concurrently from the bank s cloud server Both ATMs add $10,000 to this amount (locally at the ATM) Both write the final amount to the server What s wrong? Bank s Servers in the Cloud: Think of two simultaneous deosits of $10,000 into your bank account, each from one ATM connected to a different server. Both ATMs read initial amount of $1000 concurrently from the bank s cloud server Both ATMs add $10,000 to this amount (locally at the ATM) Both write the final amount to the server What s wrong? The ATMs need mutually exclusive access to your account entry at the server (or, to executing the code that modifies the account entry) 3 4 Mutual Exclusion Critical section roblem Piece of code (at all clients) for which we need to ensure there is at most one client executing it at any oint of time. Solutions: Semahores, mutexes, etc. in single-node OS Message-assing-based rotocols in distributed systems:» enter() the critical section» AccessResource() in the critical section» exit() the critical section Distributed mutual exclusion requirements: Safety At most one rocess may execute in CS at any time Liveness Every request for a CS is eventually granted Ordering (desirable) Requests are granted in the order they were made Mutexes To synchronize access of multile threads to common data structures Allows two oerations: lock() while true: // each iteration atomic if lock not in use: label lock in use break unlock() label lock not in use 5 6 C 1

2 Semahores How Are Mutexes Used? To synchronize access of multile threads to common data structures Semahore S=1; Allows two oerations wait(s) (or P(S)): while(1){ // each execution of the while loo is atomic if (S > 0) S--; break; } signal(s) (or V(S)): S++; Each while loo execution and S++ are each atomic oerations mutex L= UNLOCKED; ATM1: lock(l); // enter // critical section obtain bank amount; add in deosit; udate bank amount; unlock(l); // exit extern mutex L; ATM2 lock(l); // enter // critical section obtain bank amount; add in deosit; udate bank amount; unlock(l); // exit 7 8 Distributed Mutual Exclusion Performance Criteria Bandwidth: the total number of messages sent in each entry and exit oeration. Client delay: the delay incurred by a rocess at each entry and exit oeration (when no other rocess is in, or waiting) (We will refer mostly the entry oeration.) Synchronization delay: the time interval between one rocess exiting the critical section and the next rocess entering it (when there is only one rocess waiting) These translate into throughut the rate at which the rocesses can access the critical section, i.e., x rocesses er second. (these definitions more correct than the ones in the textbook) Assumtions/System Model For all the algorithms studied, we make the following assumtions: Each air of rocesses is connected by reliable channels (such as TCP). Messages are eventually delivered to reciients inut buffer in FIFO order. Processes do not fail (why?) Four algorithms Centralized control Token ring Ricart and Agrawala Maekawa Centralized Control A central coordinator (master or leader) Is elected (next lecture) Grants ermission to enter CS & kees a queue of requests to enter the CS. Ensures only one rocess at a time can access the CS Has a secial token er CS Oerations (token gives access to CS) To enter a CS Send a request to the coord & wait for token. On exiting the CS Send a message to the coord to release the token. Uon receit of a request, if no other rocess has the token, the coord relies with the token; otherwise, the coord queues the request. Uon receit of a release message, the coord removes the oldest entry in the queue (if any) and relies with a token. 1. Centralized Control Safety, liveness, ordering? Bandwidth? Requires 3 messages er entry + exit oeration. Client delay: one round tri time (request + grant) Synchronization delay one round tri time (release + grant) The coordinator becomes erformance bottleneck and single oint of failure C 2

3 2. Token Ring Aroach Processes are organized in a logical ring: i has a communication channel to (i+1)mod (n). Oerations: Only the rocess holding the token can enter the CS. To enter the critical section, wait assively for the token. When in CS, hold on to the token. To exit the CS, the rocess sends the token onto its neighbor. If a rocess does not want to enter the CS when it receives the token, it forwards the token to the next neighbor. Features: Safety & liveness, ordering? Bandwidth: 1 message er exit Client delay: 0 to N message transmissions. Synchronization delay between one rocess s exit from the CS and the next rocess s entry is between 1 and N-1 message transmissions. PN-1 P0 Previous holder of token P3 current holder of token next holder of token Administrivia PA2-B due Friday next week. Please do not use someone s code! Midterm on Wednesday Multile choices Examles osted Cheat sheet allowed (letter-sized, front-and-back) Recitations this Friday and next Monday for undergrads Processes requiring entry to critical section multicast a request, and can enter it only when all other rocesses have relied ositively. Use the Lamort clock and rocess id for ordering Messages requesting entry are of the form <T,i>, where T is the sender s timestam (Lamort clock) and i the sender s identity (used to break ties in T). To enter the CS set state to wanted multicast request to all rocesses (including timestam) wait until all rocesses send back rely change state to held and enter the CS On receit of a request <Ti, i> at j: if (state = held) or (state = wanted & (Tj, j)<(ti,i)), enqueue request rely to i On exiting the CS change state to release and rely to all queued requests On initialization To enter the section state := WANTED; Multicast request to all rocesses; T := request s timestam; Wait until (number of relies received = (N 1)); state := HELD; On receit of a request <T i, i > at j (i j) if (state = HELD or (state = WANTED and (T, j ) < (T i, i ))) queue request from i without relying; rely immediately to i ; To exit the critical section rely to any queued requests; 1 Rely Rely 2 Rely C 3

4 Analysis: Ricart & Agrawala Safety, liveness, and ordering? Bandwidth: 2(N-1) messages er entry oeration N-1 unicasts for the multicast request + N-1 relies N-1 unicast messages er exit oeration Client delay One round-tri time Synchronization delay One message transmission time Simle examle P0 P A more comlex examle P0 P3 P4 P5 P6 P7 P8 Observation: no need to have all eers rely Only need to have a subset of eers as long as all subsets overla. Voting set: a subset of rocesses that grant ermission to enter a CS Voting sets are chosen so that for any two rocesses, i and j, their corresonding voting sets have at least one common rocess. Each rocess i is associated with a voting set v i (of rocesses) Each rocess belongs to its own voting set The intersection of any two voting sets is non-emty Each voting set is of size K Each rocess belongs to M other voting sets Maekawa s Algorithm Part 1 Multicasts messages to a (voting) subset of rocesses To access a critical section, i requests ermission from all other rocesses in its own voting set v i Voting set member gives ermission to only one requestor at a time, and queues all other requests Guarantees safety Maekawa showed that K=M= N works best One way of doing this is to ut N rocesses in a N by N matrix and take union of row & column containing i as its voting set. On initialization 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) queue request from i without relying; send rely to i ; voted := TRUE; Continues on next slide C 4

5 Maekawa s Algorithm Part 2 For i to exit the critical section Multicast release to all rocesses in V i ; On receit of a release from i at j if (queue of requests is non-emty) remove head of queue from k, say; send rely to k ; voted := TRUE; voted := FALSE; Maekawa s Algorithm Analysis Bandwidth: 2 N messages er entry, N messages er exit Better than Ricart and Agrawala s (2(N-1) and N-1 messages) Client delay: One round tri time Same as Ricart and Agrawala Synchronization delay: One round-tri time Worse than Ricart and Agrawala May not guarantee liveness (may deadlock) How? P Summary Mutual exclusion Coordinator-based token Token ring Ricart and Agrawala s timestam algorithm Maekawa s algorithm Acknowledgements These slides contain material develoed and coyrighted by Indranil Guta (UIUC) C 5