Distributed Mutual Exclusion Algorithms Course: Distributed Computing Faculty: Dr. Rajendra Prasath Spring 2019
About this topic This course covers various concepts in Mutual Exclusion in Distributed Systems. We will also focus on different types of distributed mutual exclusion algorithms in distributed contexts and their analysis 2 Rajendra, IIIT Sri City
RECAP What did you learn so far? What did you learn so far? è Challenges in Message Passing systems è Distributed Sorting è Space-Time Diagram è Partial Ordering / Causal Ordering è Concurrent Events è Local Clocks and Vector Clocks è Distributed Snapshots è Termination Detection è Topology Abstraction and Overlays è Leader Election Problem in Rings è Message Ordering / Group Communications 3 Rajendra, IIIT Sri City
Topics to focus on opics to focus on … For End Semester è Distributed Mutual Exclusion è Deadlock Detection è Check pointing and rollback recovery è Self-Stabilization è Distributed Consensus è Reasoning with Knowledge è Peer – to – peer computing and Overlays è Authentication in Distributed Systems 4 Rajendra, IIIT Sri City
Mutual Exclusion in Distributed Systems Let us explore mutex algorithms proposed for various interconnection networks 5 Rajendra, IIIT Sri City
Why do we need Why do we need MutEx MutEx? ? è Mutual Exclusion è Operating systems: Semaphores è In a single machine, you could use semaphores to implement mutual exclusion è How to implement semaphores? Inhibit interrupts è Use clever instructions (e.g. test-and-set) è è On a multiprocessor shared memory machine, only the latter works 6 Rajendra, IIIT Sri City
Char Characteristics acteristics è Processes communicate only through messages – no shared memory or no global clocks è Processes must expect unpredictable message delays è Processes coordinate access to shared resources (printer, file, etc.) that should be used in a mutually exclusive manner 7 Rajendra, IIIT Sri City
Race Conditions Race Conditions è Consider Online systems – For example, Airline reservation systems maintain records of available seats è Suppose two people buy the same seat, because each checks and finds the seat available, then each buys the seat è Overlapped accesses generate different results than serial accesses è race condition 8 Rajendra, IIIT Sri City
Distributed Mutual Exclusion Distributed Mutual Exclusion è Needs è Only one process should be in critical section at any point of time è What about resources? 9 Rajendra, IIIT Sri City
Distributed Mutual Exclusion Distributed Mutual Exclusion è No Deadlocks – no set of sites should be permanently blocked, waiting for messages from other sites in that set è No starvation – no site should have to wait indefinitely to enter its critical section, while other sites are executing the CS more than once è Fairness - requests honored in the order they are made. This means processes have to be able to agree on the order of events. (Fairness prevents starvation.) è Fault Tolerance – the algorithm is able to survive a failure at one or more sites 10 Rajendra, IIIT Sri City
Distributed Distributed MutEx MutEx – An overview An overview Token-based solution: Processes share a special message known as a token è Token holder has right to access shared resource è Wait for/ask for (depending on algorithm) token; enter Critical Section (CS) when it is obtained, pass to another process on exit or hold until requested (depending on algorithm) è If a process receives the token and doesn’t need it, just pass it on 11 Rajendra, IIIT Sri City
Distributed Distributed MutEx MutEx – A F Few Issues ew Issues è Who can access the resource? è When does a process to be privileged to access the resource? è How long does a process access the resource? Any finite duration? è How long can a process wait to be privileged? è Computation complexity of the solution 12 Rajendra, IIIT Sri City
Types of ypes of Distributed Distributed MutEx MutEx è Token-based distributed mutual exclusion algorithms è Suzuki – Kasami’s Algorithm è Non-token based distributed mutual exclusion algorithms è Lamport’s Algorithm è Ricart-Agartala’s Algorithm 13 Rajendra, IIIT Sri City
Tok oken Based Methods en Based Methods Advantages: è Starvation can be avoided by efficient organization of the processes è Deadlock is also avoidable Disadvantage: Token Loss è Must initiate a cooperative procedure to recreate the token è Must ensure that only one token is created! 14 Rajendra, IIIT Sri City
Non- Non-Tok oken Based Methods en Based Methods è Permission-based solutions: a process that wishes to access a shared resource must first get permission from one or more other processes. è Avoids the problems of token-based solutions, but is more complicated to implement 15 Rajendra, IIIT Sri City
Performance erformance Analysis Analysis è Guarantees mutual exclusion è No starvation: Only if requests served in order è No deadlock è Fault tolerant? è Single point of failure è Blocking requests mean client processes have difficulty distinguishing crashed coordinator from long wait è Bottlenecks è The solution is simple and ease 16 Rajendra, IIIT Sri City
Quorum Based algorithms Quorum Based algorithms Why Quorum based algorithm? è Lamports and Ricard-Agrawala’ algorithm requires permission from all processes to enter into the critical section. Modifications: è Is it necessary to obtain permission from all processes before entering into the CS? è How to reduce the message exchanges and increase the performance of MutEx algorithm? 17 Rajendra, IIIT Sri City
Quorum Based algorithms Quorum Based algorithms What is a Quorum? è There are n requesting processes in a distributed system and any process may request for CS. è Can we form such a subset of processes who request for Critical Section? YES !! è Such a set is said to be a Request Set or Quorum è In fact, we will have a separate Request set for each process P i 18 Rajendra, IIIT Sri City
Quorum - Definition Quorum - Definition è A quorum system is a collection of subsets of processes, called quorums, such that each pair of quorums have a non-empty intersection è How do we formally define a quorum of processes in a distributed system? è Let us look at some examples 19 Rajendra, IIIT Sri City
Quorum Quorum – Why? Why? è Process may not respond or may go down (any kind of failure) è The requesting process can not get REPLY from all remaining processes è It would infinitely wait for CS !! 20 Rajendra, IIIT Sri City
Quorum Quorum – Why? Why? è Can the requesting process get permission from a quorum of processes to enter into CS? 21 Rajendra, IIIT Sri City
Quorum - Definition Quorum - Definition More Formally, è Given a set of processes P = {P 1 , P 2 , . . . , P n } è A quorum system Q ⊆ 2 P is a set of subsets of P such that for all Q 1 , Q 2 in Q : Q 1 ∩ Q 2 ≠ empty è Each Q i in Q is called a quorum 22 Rajendra, IIIT Sri City
Maekawa Maekawa’s Algorithm Algorithm è Permission obtained from only a subset of other processes, called the Request Set (or Quorum) è Separate Request Set R i , for each process i 23 Rajendra, IIIT Sri City
Maekawa Maekawa’s Algorithm Algorithm Requirements è For all i, j: R i ∩ R j ≠ Φ è For all i: i Є R i è For all i: | R i | = K , for some K è Any node i is contained in exactly D Request Sets, for some Request set D è K = D = sqrt(N) for Maekawa's algorithm 24 Rajendra, IIIT Sri City
Maekawa Maekawa’s Algorithm - Steps Algorithm - Steps To Request Critical Section: è P i sends REQUEST message to all process in R i On receiving a REQUEST message: è Send a REPLY message if no REPLY message has been sent since the last RELEASE message is received. è Update status to indicate that a REPLY has been sent. è Otherwise, queue up the REQUEST To enter critical section: è P i enters critical section after receiving REPLY from all nodes in R i 25 Rajendra, IIIT Sri City
Maekawa Maekawa’s Algorithm Algorithm – Steps Steps (contd contd) To release critical section: è Send RELEASE message to all nodes in R i è On receiving a RELEASE message, send REPLY to next node in queue and delete the node from the queue. è If queue is empty, update status to indicate no REPLY message has been sent 26 Rajendra, IIIT Sri City
Computation Complexity Computation Complexity è Message Complexity: 3 * sqrt (N) è Synchronization delay è 2*(max message transmission time) è Major problem: DEADLOCK possible è Need three more types of messages (FAILED, INQUIRE, YIELD) to handle deadlock. è Message complexity can be 5* sqrt(N N) è Important Issue: è How to build the request sets? 27 Rajendra, IIIT Sri City
Tok oken Ring en Ring Appr Approach oach è Single token circulates, enter CS when token is present è Mutual exclusion obvious è Algorithms differ in how to find and get the token è Uses sequence numbers rather than timestamps to differentiate between old and current requests 28 Rajendra, IIIT Sri City
Tok oken Rings en Rings – Illustr Illustration ation è Request movements in an unidirectional ring network Previous holder of token P 0 current holder of token P 1 P N-1 P 2 next holder of token P 3 29 Rajendra, IIIT Sri City
Recommend
More recommend
