The document discusses mutual exclusion algorithms for distributed systems, focusing on both non-token and token-based methods such as Lamport’s, Ricart-Agrawala’s, and Raymond’s tree-based algorithm. It explores the state transitions, request handling, and token management necessary for ensuring mutual exclusion while avoiding deadlock and starvation. Performance metrics are examined, including message overhead and response time, with the goal of optimizing efficiency in distributed systems.

1. Mutual Exclusion in Distributed
Systems
Name : Ajay Kharat
ID : 2019H1030011P
BITS-Pilani

2. Mutual Exclusion Algorithms for
Distributed Systems
•Classification
•Non Token Based
•Lamport’s
•Ricart Agrawala’s
•Maekawa’s
•Token Based
•Suzuki Kasami’s Broadcast
•Singhal’s Heuristics
•Raymond’s Tree Based

3. System
SV [1…..N] : System State
SN [1…..N] : Highest Seq. No.
Token
TSV [1…..N] : System State
TSN [1…..N] : Highest Seq. No.
Singhal’s Heuristic Algorithm

4. S1
S2
S3
S4
SV [ H N N N ]
SN [ 0 0 0 0 ]
SV [ R N N N ]
SN [ 0 0 0 0 ]
SV [ R R N N ]
SN [ 0 0 0 0 ]
SV [ R R R N ]
SN [ 0 0 0 0 ]
TSV [ N N N N ]
TSN [ 0 0 0 0 ]
STATES
R : REQUESTING A TOKEN
H : HOLDING IDLE TOKEN
E : EXECUTING IN CRITICAL SECTION
N:NONE OF THE ABOVE

5. S1
S2
S3
S4
SV [ H N N N ]
SN [ 0 0 0 0 ]
SV [ R R N N ]
SN [ 0 1 0 0 ]
SV [ R R N N ]
SN [ 0 0 0 0 ]
SV [ R R R N ]
SN [ 0 0 0 0 ]
TSV [ N N N N ]
TSN [ 0 0 0 0 ]
STATES
R : REQUESTING A TOKEN
H : HOLDING IDLE TOKEN
E : EXECUTING IN CRITICAL SECTION
N:NONE OF THE ABOVE
S2 is Requesting
Token
REQUEST Only “HRE”

6. S1
S2
S3
S4
SV [ H N N N ]
SN [ 0 0 0 0 ]
SV [ R R N N ]
SN [ 0 1 0 0 ]
SV [ R R N N ]
SN [ 0 0 0 0 ]
SV [ R R R N ]
SN [ 0 0 0 0 ]
TSV [ N N N N ]
TSN [ 0 0 0 0 ]
STATES
R : REQUESTING A TOKEN
H : HOLDING IDLE TOKEN
E : EXECUTING IN CRITICAL SECTION
N:NONE OF THE ABOVE
RQ (2,1)
S2 sends Request to S1

7. S1
S2
S3
S4
SV [ H N N N ]
SN [ 0 0 0 0 ]
SV [ R R N N ]
SN [ 0 1 0 0 ]
SV [ R R N N ]
SN [ 0 0 0 0 ]
SV [ R R R N ]
SN [ 0 0 0 0 ]
TSV [ N N N N ]
TSN [ 0 0 0 0 ]
STATES
R : REQUESTING A TOKEN
H : HOLDING IDLE TOKEN
E : EXECUTING IN CRITICAL SECTION
N:NONE OF THE ABOVE
RQ (2,1)
S1 updates itself and
Token(if reqd)

8. S1
S2
S3
S4
SV [ H N N N ]
SN [ 0 1 0 0 ]
SV [ R R N N ]
SN [ 0 1 0 0 ]
SV [ R R N N ]
SN [ 0 0 0 0 ]
SV [ R R R N ]
SN [ 0 0 0 0 ]
TSV [ N N N N ]
TSN [ 0 0 0 0 ]
STATES
R : REQUESTING A TOKEN
H : HOLDING IDLE TOKEN
E : EXECUTING IN CRITICAL SECTION
N:NONE OF THE ABOVE
S1 updates itself and
Token(if reqd)
RQ (2,1)

9. State of System Receiving the Request
Requesting Mode R
Executing Mode E
Holding idle Token H
None of the Above N
Action
Accept the Request, Inform the
sender about its own status
Accept the Request
Accept the Request and update
the Token
Accept the Request

10. S1
S2
S3
S4
SV [ N R N N ]
SN [ 0 1 0 0 ]
SV [ R R N N ]
SN [ 0 1 0 0 ]
SV [ R R N N ]
SN [ 0 0 0 0 ]
SV [ R R R N ]
SN [ 0 0 0 0 ]
TSV [ N R N N ]
TSN [ 0 1 0 0 ]
STATES
R : REQUESTING A TOKEN
H : HOLDING IDLE TOKEN
E : EXECUTING IN CRITICAL SECTION
N:NONE OF THE ABOVE
Token Updated

11. S1
S2
S3
S4
SV [ N R N N ]
SN [ 0 1 0 0 ]
SV [ R E N N ]
SN [ 0 1 0 0 ]
SV [ R R N N ]
SN [ 0 0 0 0 ]
SV [ R R R N ]
SN [ 0 0 0 0 ]
TSV [ N R N N ]
TSN [ 0 1 0 0 ]
STATES
R : REQUESTING A TOKEN
H : HOLDING IDLE TOKEN
E : EXECUTING IN CRITICAL SECTION
N:NONE OF THE ABOVE
S1 completes CS
Sends Token to S2 S2 sets status to E and
Executes CS

12. S1
S2
S3
S4
SV [ N R N N ]
SN [ 0 1 0 0 ]
SV [ R N N N ]
SN [ 0 1 0 0 ]
SV [ R R N N ]
SN [ 0 0 0 0 ]
SV [ R R R N ]
SN [ 0 0 0 0 ]
TSV [ N N N N ]
TSN [ 0 1 0 0 ]
STATES
R : REQUESTING A TOKEN
H : HOLDING IDLE TOKEN
E : EXECUTING IN CRITICAL SECTION
N:NONE OF THE ABOVE
S2 comes out of CS
Sets status to N
Token
Updated

13. If System has latest information Update the
Token
Else update itself from
Token
Information : Sequence Nos. possessed by System and Token
if SN > TNS , System has latest information

14. S1
S2
S3
S4
SV [ N R N N ]
SN [ 0 1 0 0 ]
SV [ R N N N ]
SN [ 0 1 0 0 ]
SV [ R R N N ]
SN [ 0 0 0 0 ]
SV [ R R R N ]
SN [ 0 0 0 0 ]
TSV [ N N N N ]
TSN [ 0 1 0 0 ]
STATES
R : REQUESTING A TOKEN
H : HOLDING IDLE TOKEN
E : EXECUTING IN CRITICAL SECTION
N:NONE OF THE ABOVE
S2 updates itself

15. S1
S2
S3
S4
SV [ N R N N ]
SN [ 0 1 0 0 ]
SV [ N N N N ]
SN [ 0 1 0 0 ]
SV [ R R N N ]
SN [ 0 0 0 0 ]
SV [ R R R N ]
SN [ 0 0 0 0 ]
TSV [ N N N N ]
TSN [ 0 1 0 0 ]
STATES
R : REQUESTING A TOKEN
H : HOLDING IDLE TOKEN
E : EXECUTING IN CRITICAL SECTION
N:NONE OF THE ABOVE
S2 updates itself

16. S1
S2
S3
S4
SV [ N H N N ]
SN [ 0 1 0 0 ]
SV [ N H N N ]
SN [ 0 1 0 0 ]
SV [ N H N N ]
SN [ 0 1 0 0 ]
SV [ N H N N ]
SN [ 0 1 0 0 ]
TSV [ N N N N ]
TSN [ 0 1 0 0 ]
STATES
R : REQUESTING A TOKEN
H : HOLDING IDLE TOKEN
E : EXECUTING IN CRITICAL SECTION
N:NONE OF THE ABOVE
S2 sets its status to H
All systems are updated

17. S1
S2
S3
S4
SV [ N H N N ]
SN [ 0 1 0 0 ]
SV [ N H N N ]
SN [ 0 1 0 0 ]
SV [ N H R N ]
SN [ 0 1 1 0 ]
SV [ N H N N ]
SN [ 0 1 0 0 ]
TSV [ N N N N ]
TSN [ 0 1 0 0 ]
STATES
R : REQUESTING A TOKEN
H : HOLDING IDLE TOKEN
E : EXECUTING IN CRITICAL SECTION
N:NONE OF THE ABOVE
Contd.. S3 makes a REQUEST
REQUEST Only “HRE”
R(3,1)

18. S1
S2
S3
S4
SV [ N H N N ]
SN [ 0 1 0 0 ]
SV [ N H R N ]
SN [ 0 1 1 0 ]
SV [ N H R N ]
SN [ 0 1 1 0 ]
SV [ N H N N ]
SN [ 0 1 0 0 ]
TSV [ N N R N ]
TSN [ 0 1 1 0 ]
STATES
R : REQUESTING A TOKEN
H : HOLDING IDLE TOKEN
E : EXECUTING IN CRITICAL SECTION
N:NONE OF THE ABOVE
S2 sets S3’s status to R
S2 then updates the TOKEN for S3

19. S1
S2
S3
S4
SV [ N H N N ]
SN [ 0 1 0 0 ]
SV [ N N R N ]
SN [ 0 1 1 0 ]
SV [ N N E N ]
SN [ 0 1 1 0 ]
SV [ N H N N ]
SN [ 0 1 0 0 ]
TSV [ N N R N ]
TSN [ 0 1 1 0 ]
STATES
R : REQUESTING A TOKEN
H : HOLDING IDLE TOKEN
E : EXECUTING IN CRITICAL SECTION
N:NONE OF THE ABOVE
S2 sets its own status to N
Sends TOKEN to S3
S3 sets status to E
Executes CS

20. S1
S2
S3
S4
SV [ N H N N ]
SN [ 0 1 0 0 ]
SV [ N N R N ]
SN [ 0 1 1 0 ]
SV [ N H N N ]
SN [ 0 1 1 0 ]
SV [ N H N N ]
SN [ 0 1 0 0 ]
TSV [ N N R N ]
TSN [ 0 1 1 0 ]
STATES
R : REQUESTING A TOKEN
H : HOLDING IDLE TOKEN
E : EXECUTING IN CRITICAL SECTION
N:NONE OF THE ABOVE
S3 comes out of CS
Looks for any other ‘R’

21. S1
S2
S3
S4
SV [ N N H N ]
SN [ 0 1 1 0 ]
SV [ N N H N ]
SN [ 0 1 1 0 ]
SV [ N N H N ]
SN [ 0 1 1 0 ]
SV [ N N H N ]
SN [ 0 1 1 0 ]
TSV [ N N N N ]
TSN [ 0 1 1 0 ]
STATES
R : REQUESTING A TOKEN
H : HOLDING IDLE TOKEN
E : EXECUTING IN CRITICAL SECTION
N:NONE OF THE ABOVE
S2 sets its own status to H
All sites are then updated

22. DeadLock and Starvation
Request sent to only those
systems who possess the Token or
will get Token in near future : E, R,
or H
If RQ is sent to any other system
if ‘N’ systems send
requests to each other : Deadlock
if a system sends request
to N system : Starvation
S1
S2
SV [ H N N N ]
SN [ 0 1 0 0 ]
SV [ R N N N ]
SN [ 0 1 0 0 ]
S3
SV [ R N N N ]
SN [ 0 1 0 0 ]

23. Correctness and Performance
Is the Algorithm Correct ? Will it ensure Mutual Exclusion ? YES
Presence of Token is necessary for CS to be executed
Only 1 system possesses the Token
What is the Performance metric and measure of this Algorithm ?
Less message overhead. Only few selected systems are requested
for Token
Avg/Max Message Traffic : N/2 or N (N : No. of systems)
Synchronization Delay : T (Delay between two consecutive CS
executions)
Response Time : 2T + CS execution Time (E)
Token values can be Binary {0,1} representing {R or N}

24. Raymond’s Tree Based Algorithm
All the sites have a Holder variable (pointer) to their neighbors
(parent) eventually reaching the site possessing the token
6
2 3
4 5
1
7
TOKEN
QUEUE
SITES

25. Raymond’s Tree Based Algorithm
Site 4 requests the TOKEN. Sends REQUEST to Site 2
Both sites update their queues, eventually requesting TOKEN holder
6
2 3
4 5
1
7
TOKEN
4
R4
4
2

26. Raymond’s Tree Based Algorithm
TOKEN site serves the REQUEST of site 2
6
2 3
4 5
1
7
4
R4
4

27. Raymond’s Tree Based Algorithm
6
2 3
4 5
1
7
6 7
6 7 3
Site 2 sends TOKEN to requesting Site 4, 4 executes the CS
Site 6 and 7 also REQUEST for TOKEN

28. Raymond’s Tree Based Algorithm
Each site enroute to TOKEN Site update their entries and forward the
REQUESTs, eventually reaching TOKEN site
6
2 3
4 5
1
7
2 6 7
6 7 3
3
1

29. Raymond’s Tree Based Algorithm
TOKEN site serves the REQUESTs of sites and forward the TOKEN
6
2 3
4 5
1
7
6 7
6 7 3
3
1

30. Raymond’s Tree Based Algorithm
6
2 3
4 5
1
7
6 7
6 7 3
3

31. Raymond’s Tree Based Algorithm
The requesting site gets the TOKEN and executes CS
6
2 3
4 5
1
7
7
7 3

32. Raymond’s Tree Based Algorithm
Site 3 sends the REQUEST for Site 7 to TOKEN site
6
2 3
4 5
1
7
7
7 3
R3
3

33. Raymond’s Tree Based Algorithm
Site 6 sends the TOKEN to requesting site and updates its queue
6
2 3
4 5
1
7
7 3
7

34. Raymond’s Tree Based Algorithm
Site 3 sends the TOEKN to Site 7 which then executes CS
6
2 3
4 5
1
7
3
7

35. Raymond’s Tree Based Algorithm
Site 3 sends the REQUEST for itself to TOKEN site
6
2 3
4 5
1
7
3
R3
3

36. Raymond’s Tree Based Algorithm
TOKEN site sends the TOKEN to requesting site
ALL REQUESTs are now fulfilled
6
2 3
4 5
1
7

37. Correctness and Performance
Is the Algorithm Correct ? Will it ensure Mutual Exclusion ? YES
Presence of Token is necessary for CS to be executed
Only 1 system possesses the Token
Tree has no cycles 🡪 no Deadlock
Each site receives the Token 🡪 no Starvation
What is the Performance metric and measure of this Algorithm ?
Average message complexity : O(log N) (avg distance between 2
sites)
Synchronization Delay : (T log N ) /2 (T : avg message delay)
Site can execute CS when it gets the TOKEN even if it is not its turn
On heavy loads, Synchrinozation Delay : T
Response Time : T (log N) +E (time to execute CS)

38. That’s it..
Thank You