11-10-2024

➢ Distributed Mutual Exclusion Algorithms

➢ Dead Lock detection

Vijay Katta 1

Vijay Katta 2

1
 11-10-2024

➢ Mutual exclusion:Concurrent access of

processes to a shared resource or data is
executed in mutually exclusive manner.

➢ Only one process is allowed to execute the

critical section (CS) at any given time.

Vijay Katta 3

➢ In a distributed system, shared variables

(semaphores) or a local kernel cannot be used
to implement mutual exclusion.

➢ Message passing is the sole means for

implementing distributed mutual exclusion.

Vijay Katta 4

2
 11-10-2024

➢ Distributed mutual exclusion algorithms must

deal with

➢ unpredictable message delays and

➢ incomplete knowledge of the system state.

Vijay Katta 5

Mutual Exclusion
algorithms

Centralized Distributed
algorithms Algorithms

Controlled
Contention Based Algorithms
Non Token based Algorithms (Token based
algorithms)

Timestamp prioritized
Tree Structure
schemes

Voting schemes Broadcast Structure

Ring Structure

Vijay Katta 6

3
 11-10-2024

a) . Process 1 asks the coordinator for permission to enter a critical region.

Permission is granted
b) . Process 2 then asks permission to enter the same critical region. The
coordinator does not reply.
c) . When process 1 exits the critical region, it tells the coordinator, which then
replies to 2

Vijay Katta 7

 Advantages
➢ Fair algorithm, grants in the order of requests
➢ The scheme is easy to implement
➢ Scheme can be used for general resource allocation

Critical Question: When there is no reply, does this mean that the
coordinator is “dead” or just busy?
 Shortcomings
➢ Single point of failure. No fault tolerance
➢ Confusion between No-reply and permission denied
➢ Performance bottleneck of single coordinator in a large system

Vijay Katta 8

4
 11-10-2024

Vijay Katta 9

➢ Token based approach

➢ Non-token based approach

Vijay Katta 10

5
 11-10-2024

➢ A unique token is shared among the sites.

➢ A site is allowed to enter its CS if it possesses

the token.

➢ Mutual exclusion is ensured because the

token is unique.

Vijay Katta 11

➢ Two or more successive rounds of messages

are exchanged among the sites to determine
which site will enter the CS next.

Vijay Katta 12

6
 11-10-2024

➢ System Model
➢ The system consists of N sites, (S1, S2, ..., SN ).

➢ We assume that a single process is running on

each site. The process at site Si is denoted by pi .

➢ A site can be in one of the following three states:

❖ requesting the CS,
❖ executing the CS,
❖ or neither requesting nor executing the CS (i.e., idle).

Vijay Katta 13

➢ In the ‘requesting the CS’ state, the site is blocked

and can not make further requests for the CS.

➢ In the ‘idle’ state, the site is executing outside the CS.

➢ In token-based algorithms, a site can also be in a

state where a site holding the token is executing
outside the CS (called the idle token state).

➢ At any instant, a site may have several pending

requests for CS. A site queues up these requests and
serves them one at a time.
Vijay Katta 14

7
 11-10-2024

➢ Safety Property: At any instant, only one process can

execute the critical section.
➢ Liveness Property: This property states the absence of
deadlock and starvation. Two or more sites should not
endlessly wait for messages which will never arrive.
➢ Fairness: Each process gets a fair chance to execute the
CS. Fairness property generally means the CS execution
requests are executed in the order of their arrival FIFO
(time is determined by a logical clock) in the system.
➢ Fault tolerance :-

Vijay Katta 15

➢ The performance is generally measured by the

following four metrics:
➢ Message complexity: The number of messages
required per CS execution by a site.
➢ Synchronization delay:

➢ Response time:

➢ System throughput:

Vijay Katta 16

8
 11-10-2024

 After a site leaves the CS, it is the time required

and before the next site enters the CS.

Vijay Katta 17

➢ The time interval a request waits for its CS

execution to be over after its request messages
have been sent out

Vijay Katta 18

9
 11-10-2024

➢ The rate at which the system executes

requests for the CS.

➢ system throughput=1/(SD+E)
➢ where SD is the synchronization delay and
➢ E is the average critical section execution
time.

Vijay Katta 19

 Low and High Load Performance:

 We often study the performance of mutual exclusion
algorithms under two special loading conditions, viz., “low
load” and “high load”.

 The load is determined by the arrival rate of CS execution

requests.
 Under low load conditions, there is seldom more than
one request for the critical section present in the system
simultaneously.
 Under heavy load conditions, there is always a pending
request for critical section at a site.
Vijay Katta 20

10
 11-10-2024

1) Lamport ME Algorithm
2) The Ricart Agrawala Algorithm
3) Roucairol -Carvalho Algorithm
4) MAEKAWA’s Algorithm
5) Generalized Non token based algorithm

Vijay Katta 21

➢ Requests for CS are executed in the increasing

order of timestamps and time is determined
by Lamport logical clocks.
➢ Every site Si keeps a queue, called as
➢ request queuei ,

which contains mutual exclusion requests

ordered by their timestamps. (tsi,i).
➢ This algorithm requires communication channels
to deliver messages the FIFO order.
Vijay Katta 22

11
 11-10-2024

➢ When a site Si wants to enter the CS,

➢ it broadcasts a REQUEST(tsi ,i ) message to all
other sites and places the request on request
queuei .
➢ (tsi,i) denotes the lamport timestamp of the
request from site i.
➢ Whena site Sj receives the REQUEST(tsi , i )
message from site Si ,
➢ places site Si ’s request on request queuej and
➢ it returns a time stamped REPLY message to Si .
Vijay Katta 23

➢ Site Si enters the CS when the following

two
conditions hold:

❖L1: Si has received a message with timestamp

larger than (tsi , i ) from all other sites.

❖L2: Si ’s request is at the top of request queuei .

Vijay Katta 24

12
 11-10-2024

➢ Site Si , upon exiting the CS,

➢ removes its request from the top of its request queue and
➢ broadcasts a time stamped RELEASE message to all other
sites.

➢ When a site Sj receives a RELEASE message from

site Si ,
➢ it removes Si ’s request from its request queue.

➢ When a site removes a request from its request

queue, its own request may come at the top of the
queue, enabling it to enter the CS.

Vijay Katta 25

Vijay Katta 26

13
 11-10-2024

|(3.1)| | (2.2) (3.1)| Request Queue

at P1
P1

Reply messages:

P2
|(2. 2)| Request Queue
|(2.2) (3. 1)|
at P2

P3

Vijay Katta 27

(3.1) (2.2) (3.1)

P1

P2
(2. 2) (2.2) (3. 1) Release
Message

P3

Vijay Katta 28

14
 11-10-2024

 Purpose of REPLY messages from node i to j is to

ensure that
▪ j knows of all requests of i prior to sending the REPLY (and
therefore, possibly any request of i with timestamp lower
than j’s ’s request)
 Requires FIFO channels.
 3( n – 1 ) messages per critical section invocation
 Synchronization delay = max mesg transmission
time=T
 Requests are granted in order of increasing
timestamps.
➢ Lower timestamp higher priority.
➢ Higher Timestamp lower priority.

Vijay Katta 29

 Optimization from 3(N-1) to 2(N-1) by suppresing

REPLY. (in certain condition)

 When Sj request for CS .

▪ After sending request to all,
▪ Sj receiving request with higher timestamp (lower
priority) from Si,
▪ Sj will not send Reply message to Si and Si will
not wait for Reply because it knows Sj has lower
priority .

Vijay Katta 30

15
 11-10-2024

 Improvement over Lamport’s, merge RELEASE with

REPLY.
 Main Idea:
 node j need not send a REPLY to node i if j has a request
with timestamp lower than the request of i (since
cannot enter before j anyway in this case)
 Does not require FIFO
 2(n – 1) messages per critical section invocation
 Synchronization delay = max. message transmission
time
 Requests granted in order of increasing timestamps

Vijay Katta 31

 To request critical section:

send time stamped REQUEST message ( tsi , i)
 On receiving request ( tsi, i) at j:
send REPLY to Si
if Sj is neither requesting nor executing critical section
or
if Sj is requesting and Si’s request timestamp is smaller
than Sj’s request timestamp.
Otherwise, defer the request.
 To enter critical section:
Si enters critical section on receiving REPLY from all nodes.
 To release critical section:
send REPLY to all deferred requests.

Vijay Katta 32

16
 11-10-2024

 Improvement over Ricart-Agarwala

 Main idea
Once Si has received a REPLY from Sj,
➢ it does not need to send a REQUEST to Sj again unless
it sends a REPLY to Sj (in response to a REQUEST
from Sj)
 Message complexity varies between
0 and 2( n – 1)
 depending on the request pattern and load.
 worst case message complexity still the same

Vijay Katta 33

 Maekawa’s algorithm was the first quorum-

based mutual exclusion algorithm.

 Sites are divided into groups call request

set.

 No need to send request to all the sites but

only send request in their request set.

Vijay Katta 34

17
 11-10-2024

 The request sets for sites (i.e., quorums) in

Maekawa’s algorithm are constructed to
satisfy the following four conditions:
1) M1: (∀i ∀j : i != j, 1 ≤ i, j ≤ N :: Ri ∩ Rj != φ)
▪ There is at least one site between the request sets of
any two sites.

Vijay Katta 35

RSi RSj

RSx RSk

Vijay Katta 36

18
 11-10-2024

2) M2: (∀i : 1 ≤ i ≤ N :: Si ∈ Ri)

▪ A site can have only one outstanding REPLY message
at any time; that is, it grant permission to an incoming
request if it has not grant permission to some other
site.
3) M3: (∀i : 1 ≤ i ≤ N :: |Ri | = K)
▪ Size of request set for all site must be equal, imply
that all site must have to do equal amount of work to
invoke mutual exclusion.

Vijay Katta 37

4) M4: Any site Sj is contained in K number of Ri’s,

1 ≤ i, j ≤ N.

This relation gives |Ri | = √ N. =K

M4 enforces that exactly the same number of sites

should request permission from any site, implying
that all sites have equal responsibility in granting
permission to other site.

Vijay Katta 38

19
 11-10-2024

 Condition M1 and M2 are necessary for

correctness condition.

 Condition M3 and M4 provides desirable

features to algorithm.

Vijay Katta 39

 A site Si executes the following steps to execute the

CS.
 Requesting the critical section
▪ (a) A site Si requests access to the CS by sending
REQUEST(i) messages to all sites in its request set Ri .

▪ (b) When a site Sj receives the REQUEST(i) message, it

sends a REPLY(j) message to Si provided it hasn’t sent a
REPLY message to a site since its receipt of the last
RELEASE message.
Otherwise,
▪ it queues up the REQUEST(i) for later consideration.
Vijay Katta 40

20
 11-10-2024

 Executing the critical section

(c) Site Si executes the CS only after it has

received a REPLY message from every site in
Ri .

Vijay Katta 41

 Releasing the critical section

 (d) After the execution of the CS is over, site Si sends a
RELEASE(i) message to every site in Ri .

 (e) When a site Sj receives a RELEASE(i) message from

site Si , it sends a REPLY message to the next site
waiting in the queue and deletes that entry from the
queue.
 If the queue is empty, then the site updates its state to
reflect that it has not sent out any REPLY message
since the receipt of the last RELEASE message
Vijay Katta 42

21
 11-10-2024

1. Since the size of a request set is √ N,

2. an execution of the CS requires √ N REQUEST,
3. √ N REPLY, and
4. √ N RELEASE messages,
5. resulting in 3√ N messages per CS execution.
6. Synchronization delay in this algorithm is 2T.
1. This is because after a site Si exits the CS, it first
releases all the sites in Ri and then one of those sites
sends a REPLY message to the next site that
executes the CS.
Vijay Katta 43

 Self study:- (assignment )

 Book Name: “Advance Concept of operating
systems”, by Shivaratri and Mukesh Singhal.
 Page no.-133-134
 Section 6.9

Vijay Katta 44

22
 11-10-2024

Token Based Algorithm

Raymond’s Tree based algorithm

(Used in Google Drive)

Vijay Katta 46

23
 11-10-2024

❖ Processes are organized as a directed tree.

❖ Each edge is pointed towards the site(or root of the tree) having token

❖ Each process has a variable HOLDER, that point to an immediate

neighbor node on a directed path to the root node .(which indicates
the location of the token relative to the node itself.)

❖ At root node HOLDER points to itself.

❖ Each process keeps a REQUEST_Q that stores the request of those

neighbors or itself that have sent a REQUEST, but have not yet been
sent the token in reply.

REQUEST_Q HOLDER1 = 1
1 3

REQUEST_Q HOLDER3 = 1
2 3 8

8 REQUEST_Q HOLDER8 = 3
4 5 6 7 8

Vijay Katta 48

24
 11-10-2024

 Requesting the critical section:-

1. When a site wants to enter CS, it send request
message to the node along the directed path to
the root, provided it does not hold the token and
its request_q is empty.
2. It then add its request to its request_q.

Note:- Non empty requst_q at site indicate that the

site has sent a REQUEST message to the root
node for top entry in request_q
Vijay Katta 49

3. When a site on this path receive this message, it

places the REQUEST in its request_q and forward
the request on path to root node only if , it has not
send a REQUEST message for previously received
REQUEST.

4. When root site received the REQUEST message, it

send the token to the site from which it received
the REQUEST message and set its HOLDER
variable to point at that site.

Vijay Katta 50

25
 11-10-2024

5. When a site received the token, it delete its top

entry from its request_q, send token to the site
indicated in this entry, and sets its holder variable
to point at that site.

6. If request_q is nonempty at this point, then site

sends a REQUEST message to the site which is
pointed at by holder variable.

Vijay Katta 51

 Executing the critical section :-

7. A site enter the CS when it received the token

AND its own entry is at top of its request_q.

8. In this case, the site delete the top entry from its
request_q and enter the CS.

Vijay Katta 52

26
 11-10-2024

 Releasing the critical section:- (After completing CS)

9. If its request_q is non-empty, then it delete the top

entry from its request_q, send the token to that site,
and sets its HOLDER variable to point at that site.

Vijay Katta 53

P8 requests entry to CS
And P1 is in CS

New HOLDER1 = 3

1 3 1 1

New HOLDER3 = 8
2 3 8 2 3 8 2 3

4 5 6 7 8 8 4 5 6 7 8 8 4 5 6 7 8 New HOLDER8 = 8

Vijay Katta 54

27
 11-10-2024

1. Initial State 4. Req. by P6 7. P8 passes T to P3, to P6

1 1 3, 2 1 2
2 2 3 8, 6 2 2 3 1
2 3

4 5 7 8 4 5 6 7 8 8 4 5 6 7 8
6
6 3
2. Req. by P8 5. P1 passes T to P3 8. Req. by P7

1 3 1 2 1 2
1, 7
2 2 3 8, 6,1 2 2 3
2 3 8
4 5 6 7 8 8 4 5 6 7 8
4 5 6 7 8 8 3
6 7
3. Req. by P2 6. P3 passes T to P8 9. P6 passes T to P3, to P1
1 3, 2 1 2 1 2,3
2 2 3 8 2 2 3 6,1 2 2 3 7

4 5 6 7 8 8 4 5 6 7 8 3 4 5 6 7 8
6 7

 The Raymond Tree-Based Distributed Mutual

Exclusion Algorithm is particularly useful in
systems where minimizing the number of
messages passed in the network is crucial, such
as in large-scale distributed systems and peer-
to-peer networks.
 The algorithm organizes processes in a logical
tree, reducing the number of messages needed
to grant access to a critical section.
 Real-Time Application Example: Cloud-Based
File Sharing Systems

Vijay Katta 56

28
 11-10-2024

 In cloud-based file-sharing systems like Google Drive or Dropbox, files

stored on different servers (nodes) may require mutual exclusion when
multiple users try to edit the same file concurrently.
 The Raymond tree-based algorithm can manage file access in a
distributed manner, ensuring that only one user can edit a file at a time
without relying on a centralized server.
 Working in this Scenario:
1. Each server in the network is a node in the Raymond tree. If a user on one
server requests to edit a file, the server traverses the logical tree structure to
acquire the token (permission to enter the critical section).
2. The request is forwarded along the tree hierarchy until the token reaches the
requesting node, ensuring that only one node at a time can modify the file.
3. Once the file modification is complete, the token is returned to the tree, ready
for the next request.

Vijay Katta 57

 Bandwidth?
 Client delay?
 Synchronization delay?

 Try it at home, may be a question for next

homework (or an exam question)

 Source: K. Raymond, “A Tree-based algorithm for

distributed mutual exclusion”, ACM Transactions on
Computer Systems (TOCS), 7(1): 61-77, 1989

29
 11-10-2024

Suzuki Kasami Algorithm

(Used in Distributed Database – banking system database)

Vijay Katta 59

0 0 0 0 0 RN1
RN2 0 0 0 0 0
1 2 3 4 5
1 2 3 4 5
n=1 S1
S2 n=2

0 0 0 0 0 LN
1 2 3 4 5 Token at Site
S1
Q { } (empty) S3 n=3

RN3 0 0 0 0 0
n=5 S5 1 2 3 4 5
n=4
RN5 0 0 0 0 0
S4 0 0 0 0 0 RN4
1 2 3 4 5
1 2 3 4 5

30
 11-10-2024

 S1 won’t execute Request Part of the algorithm

 S1 enters CS as it has token
 When S1 release CS,it performs following tasks
(i) LN[1] = RN1[1]
(ii) If during S1’s CS execution, any request from other site (say
S2) have come then that Site’s id will now be entered into
the queue if RN1[2] = LN[2]+1
 So if site holding (not received from other) the token
enters CS then overall state of the system won’t change
it remains same.

 S2 does not have token so it sends REQUEST(2,1) message

to every other site
 Sites S1,S3,S4 and S5 updates their RN as follows
0 1 0 0 0
1 2 3 4 5

It may be possible that S2’s request came at S1 when S1 is under CS execution

So at this point S1 will not pass the token to S2. It will finish its CS and then adds S2
Into Queue because at that point
RN1[2] = 1 which is equal to LN[2]+1
i.e 1= 0+1
Now as the queue is not empty, so S1 pass token to S2 by removing S2 entry from
Token queue.

31
 11-10-2024

0 1 0 0 0 RN1
RN2 0 1 0 0 0
1 2 3 4 5
REQUEST(2,1) 1 2 3 4 5
n=1 S1
S2 n=2

REQUEST(2,1)
0 0 0 0 0 LN
1 2 3 4 5 Token at Site
S1
Q {S2 } [Inserted only when S1 leave CS] S3

RN3 0 1 0 0 0
n=5 S5 REQUEST(2,1) 1 2 3 4 5
REQUEST(2,1)
n=4
0 1 0 0 0
S4 0 1 0 0 0 RN4
1 2 3 4 5
1 2 3 4 5

0 1 0 0 0 RN1
RN2 0 1 0 0 0
1 2 3 4 5
1 2 3 4 5
n=1 S1
S2 n=2

0 LN0 0 0 0 LN
Token at Site S2
1 2 3 4 5

Q{s2} S3

RN3 0 1 0 0 0
n=5 S5 1 2 3 4 5
n=4
0 1 0 0 0
S4 0 1 0 0 0 RN4
1 2 3 4 5
1 2 3 4 5

32
 11-10-2024

0 1 0 0 0 RN1
RN2 0 1 0 0 0
1 2 3 4 5
1 2 3 4 5
n=1 S1
S2 n=2

0 LN1 0 0 0 LN
Token at Site S2
1 2 3 4 5

Q{} S3

RN3 0 1 0 0 0
n=5 S5 1 2 3 4 5
n=4
0 1 0 0 0
S4 0 1 0 0 0 RN4
1 2 3 4 5
1 2 3 4 5

 S2 can enter CS as token queue is empty i.e.

no other site has requested for CS and token
is currently held by S2

 When S2 release CS it updates LN[2] as

RN2[2] which is same as 1.

33
 11-10-2024

 A site updates its RN table as soon as it receives

Request message from any other site .
[At this point a site may hold an ideal token or
may be executing CS]

 When a site enters CS without sending request

message (i.e. when site wants to again enter CS
without making request) then its RN entry and LN
entry of token remains unchanged

 A site can be added in to token queue only by

the site who is releasing the CS

 A site holding the token can repeatedly enter

CS until it does not send token to some other
site.
 A site gives priority to other sites with
outstanding requests for the CS over its
pending requests for the CS
Vijay Katta 68

34
 11-10-2024

 The Suzuki-Kasami distributed mutual exclusion algorithm is used to

manage access to a shared resource in distributed systems without
needing a centralized coordinator.
 A real-time application example of this algorithm is in distributed
databases, particularly for handling transactions across multiple sites.
 Example: Distributed Database Transaction Management
▪ In a distributed database system, multiple nodes might need access to shared
data for read or write operations.
▪ For instance, in a banking system that spans across different branches, the
same account data might be accessed by different nodes.
▪ The Suzuki-Kasami algorithm ensures that only one node at a time gets
permission to update a specific account, maintaining the consistency and
correctness of the data across the network.

Vijay Katta 69

 Working in the Scenario:

1. When a branch wants to access a shared account for
modification (a critical section), it sends a request to all
other branches.
2. Using a token-passing mechanism, the algorithm ensures
that only one branch (node) gets access at any time.
3. Once the branch is done with its transaction, it releases
the token, allowing the next branch in the queue to access
the critical section.
 The Suzuki-Kasami algorithm's efficiency in terms of
message passing and its suitability for large-scale
distributed systems makes it ideal for real-time
transaction processing in such environments.

Vijay Katta 70

35