Distributed Mutual Exclusion Algorithms Course: Distributed - - PowerPoint PPT Presentation

▶
distributed mutual exclusion algorithms
SMART_READER_LITE
LIVE PREVIEW

Distributed Mutual Exclusion Algorithms Course: Distributed - - PowerPoint PPT Presentation

Sep 22, 2023 586 likes •1.03k views

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

slide-1
SLIDE 1

Distributed Mutual Exclusion Algorithms

Course: Distributed Computing Faculty: Dr. Rajendra Prasath

Spring 2019

slide-2
SLIDE 2

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

slide-3
SLIDE 3

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

RECAP

Rajendra, IIIT Sri City

3

slide-4
SLIDE 4

Topics to focus on

  • pics to focus on …

è 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

For End Semester

Rajendra, IIIT Sri City

4

slide-5
SLIDE 5

Mutual Exclusion in Distributed Systems

Let us explore mutex algorithms proposed for various interconnection networks

Rajendra, IIIT Sri City

5

slide-6
SLIDE 6

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

slide-7
SLIDE 7

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

slide-8
SLIDE 8

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

slide-9
SLIDE 9

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

slide-10
SLIDE 10

Distributed Mutual Exclusion Distributed Mutual Exclusion

è No Deadlocks – no set of sites should be permanently blocked, waiting for messages from

  • ther 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

slide-11
SLIDE 11

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

  • btained, 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

slide-12
SLIDE 12

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

slide-13
SLIDE 13

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

slide-14
SLIDE 14

Tok

  • ken Based Methods

en Based Methods

Advantages: è Starvation can be avoided by efficient

  • rganization 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

slide-15
SLIDE 15

Non- Non-Tok

  • ken 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

slide-16
SLIDE 16

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

slide-17
SLIDE 17

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

slide-18
SLIDE 18

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 Pi 18

Rajendra, IIIT Sri City

slide-19
SLIDE 19

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

slide-20
SLIDE 20

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

slide-21
SLIDE 21

Quorum Quorum – Why? Why?

è Can the requesting process get permission from a quorum of processes to enter into CS?

21

Rajendra, IIIT Sri City

slide-22
SLIDE 22

Quorum - Definition Quorum - Definition

More Formally, è Given a set of processes P = {P1, P2, . . . , Pn} è A quorum system Q ⊆ 2P is a set of subsets of P such that for all Q1, Q2 in Q: Q1 ∩ Q2 ≠ empty è Each Qi in Q is called a quorum

22

Rajendra, IIIT Sri City

slide-23
SLIDE 23

Maekawa Maekawa’s Algorithm Algorithm

è Permission obtained from only a subset

  • f other processes, called the Request

Set (or Quorum) è Separate Request Set Ri , for each process i

23

Rajendra, IIIT Sri City

slide-24
SLIDE 24

Maekawa Maekawa’s Algorithm Algorithm

Requirements

è For all i, j: Ri ∩ Rj ≠ Φ è For all i: i Є Ri è For all i: | Ri | = 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

slide-25
SLIDE 25

Maekawa Maekawa’s Algorithm - Steps Algorithm - Steps

To Request Critical Section:

è Pi sends REQUEST message to all process in Ri

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:

è Pi enters critical section after receiving REPLY from all nodes in Ri 25

Rajendra, IIIT Sri City

slide-26
SLIDE 26

Maekawa Maekawa’s Algorithm Algorithm – Steps Steps (contd

contd)

To release critical section:

è Send RELEASE message to all nodes in Ri è 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

slide-27
SLIDE 27

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

slide-28
SLIDE 28

Tok

  • ken Ring

en Ring Appr Approach

  • ach

è 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

slide-29
SLIDE 29

Tok

  • ken Rings

en Rings – Illustr Illustration ation

è Request movements in an unidirectional ring network 29

Rajendra, IIIT Sri City

P0 P1 P2 P3 PN-1 Previous holder of token next holder of token current holder of token

slide-30
SLIDE 30

Suzuki Suzuki – Kasami’ Kasami’s Algorithm Algorithm

è Broadcast a request for the token è Process with the token sends it to the requestor if it does not need it è Issues:

è Current versus outdated requests è Determining sites with pending requests è Deciding which site to give the token to

30

Rajendra, IIIT Sri City

slide-31
SLIDE 31

Data Structur Data Structures es

The token:

è Queue (FIFO) Q of requesting processes è LN[1.. n] : sequence number of request that j executed most recently

The request message:

è REQUEST( i, k): request message from node i for its kth critical section execution

Other data structures:

è RNi [1.. n] for each node i, where , RNi [ j ] is the largest sequence number received so far by i in a REQUEST message from j

31

Rajendra, IIIT Sri City

slide-32
SLIDE 32

Suzuki- Suzuki-Kasami’ Kasami’s algorithm algorithm

To request critical section:

è If i does not have token, increment RNi [ i ] and send REQUEST( i, RNi [ i ]) to all nodes è If i has token already, enter critical section if the token is idle (no pending requests), else follow rule to release critical section

On receiving REQUEST( i, sn) at ) j:

è Set RNj [ i ] = max(RNj [ i ], sn) è If j has the token and the token is idle then

è send it to i if RNj [ i ] = LN[ i ] + 1 è If token is not idle, follow rule to release critical section

32

Rajendra, IIIT Sri City

slide-33
SLIDE 33

Suzuki- Suzuki-Kasami’ Kasami’s algorithm algorithm

To enter critical section:

è Enter CS if token is present

To release critical section:

è Set LN[ i ] = RNi[ i ] è For every node j which is not in Q (in token), add node j to Q if RNi[ j ] = LN[ j ] + 1 è If Q is non empty after the above, delete first node from Q and send the token to that node 33

Rajendra, IIIT Sri City

slide-34
SLIDE 34

Complexity Complexity

è No. of messages:

è 0 if node holds the token already, è n otherwise

è Synchronization delay:

è 0 (node has the token) or è max. message delay (token is elsewhere)

è No starvation

34

Rajendra, IIIT Sri City

slide-35
SLIDE 35

Raymond’ Raymond’s s Algorithm Algorithm

è Forms a directed tree (logical) with the token token-holder as root è Each node has variable “Holder” that points to its parent on the path to the root.

è Root’s Holder variable points to itself

è Each node Pi has a FIFO request queue Qi

35

Rajendra, IIIT Sri City

slide-36
SLIDE 36

Raymond’ Raymond’s s Algorithm Algorithm

è To request critical section:

è Send REQUEST to parent on the tree, provided i does not hold the token currently and Qi is

  • empty. Then place is request in Qi

è When a non-root node j receives a request from k

è place request in Qj è send REQUEST to parent if no previous REQUEST sent

36

Rajendra, IIIT Sri City

slide-37
SLIDE 37

Raymond’ Raymond’s s Algorithm ( Algorithm (contd contd) )

When the root receives a REQUEST:

è send the token to the requesting node è set Holder variable to point to that node

When a node receives the token:

è delete first entry from the queue è send token to that node è set Holder variable to point to that node è if queue is non non-empty, send a REQUEST message to the parent (node pointed at by Holder variable)

37

Rajendra, IIIT Sri City

slide-38
SLIDE 38

Raymond’ Raymond’s s Algorithm Algorithm (contd

contd)

è To execute critical section:

è enter if token is received and own entry is at the top of the queue; delete the entry from the queue

è To release critical section:

è if queue is non non-empty, delete first entry from the queue, send token to that node and make Holder variable point to that node è If queue is still non non-empty, send a REQUEST message to the parent (node pointed at by Holder variable)

38

Rajendra, IIIT Sri City

slide-39
SLIDE 39

Featur eatures of es of Raymond’ Raymond’s s Algo Algo

è Average message complexity:

è O(log n)

è Sync. Delay

è (T log n)/2, where T = max. message delay 39

Rajendra, IIIT Sri City

slide-40
SLIDE 40

Summary Summary

è Mutual Exclusion è Various Types of MutEx algorithms

è Non-Token based algorithm è Quorum based algorithm è Token based algorithm è Suzuki – Kasami’s Algorithm è Raymond’s Tree based algorithm

è Performance Metrics

è Stay tuned ... More to come up … !!

Rajendra, IIIT Sri City

40

slide-41
SLIDE 41

How to r How to reach me? each me?

è Please leave me an email:

rajendra [DOT] prasath [AT] iiits [DOT] in

è Visit my homepage @

è http://www.iiits.ac.in/FacPages/index- rajendra.html OR è http://rajendra.2power3.com 41

Rajendra, IIIT Sri City

slide-42
SLIDE 42
  • Perspective Students (having CGPA above 8.5

and above)

  • Promising Students (having CGPA above 6.5

and less than 8.5)

  • Needy Students (having CGPA less than 6.5)
  • Can the above group help these students? (Your

work will also be rewarded)

  • You may grow a culture of collaborative

learning by helping the needy students

Help among Yourselves?

42

Rajendra, IIIT Sri City

slide-43
SLIDE 43

… Questions ???

Thanks …

Rajendra, IIIT Sri City

43