1. Chapter 6.3 Mutual Exclusion
By: Saurabh Gupta ( .edu)
Panther ID:

2. Introduction What is Mutual Exclusion and why we need it?
Concurrency and collaboration among multiple processes
Simultaneous access to the resources
Mutual Exclusion algorithms are of two types:
Token-Based
Permission-Based
Fundamental to distributed systems is the concurrency and collaboration
among multiple processes. In many cases, this also means that processes will need
to simultaneously access the same resources. To prevent that such concurrent ac-
cesses corrupt the resource, or make it inconsistent, solutions are needed to grant
mutual exclusive access by processes. In this section, we take a look at some of
the more important distributed algorithms that have been proposed.
In token-based solutions mutual exclusion is achieved by passing a
special message between the processes, known as a token. There is only one
token available and who ever has that token is allowed to access the shared re-
source. When finished, the token is passed on to a next process. If a process hav-
ing the token is not interested in accessing the resource, it simply passes it on.
Token-based solutions have a few important properties. First, depending on
the how the processes are organized, they can fairly easily ensure that every proc-
ess will get a chance at accessing the resource. In other words, they avoid starva-
tion. Second, deadlocks by which several processes are waiting for each other to
proceed, can easily be avoided, contributing to their simplicity. Unfortunately, the
main drawback of token-based solutions is a rather serious one: when the token is
lost (e.g., because the process holding it crashed), an intricate distributed proce-
dure needs to be started to ensure that a new token is created, but above all, that it
is also the only token.
many distributed mutual exclusion algorithms follow a permission-based approach.
In this case. a process wanting to access the resource first requires the permission
of other processes. There are many different ways toward granting such a permission
and in the sections that follow we will consider a few of them

3. Overview Centralized Algorithm Decentralized Algorithm
Distributed Algorithm
Token Ring Algorithm
Current Trends
Future Work

4. Centralized Algorithm
Simple and Simulation of a one-processor system
One process is elected as the coordinator
A queue is used for requests and is controlled by the
coordinator
Easy to implement

5. Centralized Algorithm
Image taken from (Distributed Systems Principles and Paradigms - Tannenbaum&Steen, 2006)

6. Centralized Algorithm
Advantages:
Easy to implement only three messages per use of resource
(request, grant, release)
no starvation
Disadvantages:
Coordinator is single point of failure
Single coordinator can be a performance bottleneck

7. Decentralized Algorithm
Voting algorithm that can be executed using
DHT-based system
Resources are assumed to be replicated n times, and
each resource has its own coordinator
When needed access, a majority vote from > n/2 coordinators
shall be granted for accepting the request

8. Decentralized Algorithm
Let p be the probability that a coordinator resets during a time
interval t. The probability P [k] that k out of m coordinators reset
during the same interval is then
Given that at least 2m - n coordinators need to reset in order to violate
the correctness of the voting mechanism, the probability that such a
violation occurs is then P [k].
With n = 32 and m = 0.75n, the probability is surely smaller than the
availability of any resource.

9. Decentralized Algorithm
n replicas of a resource has n coordinators
All processes that want to access a resource send requests to each coordinator
The process which gets the majority vote (m >n/2) gets the permission
The other processes who lost the vote will release the acquired votes
and retry after a random period of time

10. Distributed Algorithm
When a process wants to access a resource it builds a message
containing: name of the resource, process number, current time
Algorithm:
Process creates a message for the resource (name, proc.no, time)
Process sends it to everyone including itself
When receiver (another process) gets the message, it can do following:
If receiver does not want to access the resource it sends OK to requesting process
If receiver already has access, it queues the message from requester
If receiver also wants to access, but not yet done so, then It compares the time of the
received message with the one that it had sent to others
If the incoming message has a lower timestamp, the receiver sends back an OK message.
If its own message has a lower timestamp, the receiver queues the incoming request and
sends nothing.

11. Distributed Algorithm
Process 0 sends everyone a request with timestamp 8, while at the same time,
process 2 sends everyone a request with timestamp 12. Process 1 is not interested
in the resource, so it sends OK to both senders. Processes 0 and 2 both see the
conflict and compare timestamps. Process 2 sees that it has lost, so it grants per-
mission to 0 by sending OK. Process 0 now queues the request from 2 for later
processing and access the resource, as shown in Fig. 6-15(b). When it is finished,
it removes the request from 2 from its queue and sends an OK message to process
2, allowing the latter to go ahead, as shown in Fig. 6-15(c). The algorithm works
because in the case of a conflict, the lowest timestamp wins and everyone agrees
on the ordering of the timestamps.
Image taken from (Tannenbaum&Steen, 2006)

12. Distributed Algorithm
Pros:
Mutual exclusion is guaranteed without deadlock or starvation.
Cons:
Whenever either a request or a reply is lost, the sender times out and
keeps trying until either a reply comes back or the sender concludes that
the destination is dead.

13. Token Ring Algorithm
In software, a logical ring is constructed in which each process is assigned a position in the ring
Token provides access to resources
Token can only be handled by one node at a certain time
Token circulates the ring, when one does not need the resources
Image taken from (Tannenbaum&Steen, 2006)

14. Current Trends Group Mutual Exclusion
A process requests a “session”.
Processes requesting the same session can be in
critical section simultaneously.
Processes requesting different sessions can not.
e.g. a CD jukebox

15. Current Trends Local Mutual Exclusion
Local mutual exclusion ensures that critical sections
of neighboring nodes must be executed in exclusion
with its neighbors

16. Current Trends K-Mutual Exclusion
The distributed k-mutual exclusion is the problem of allowing at most k processes to access their critical sections simultaneously.
This might be the consequence where k identical copies of a
resource are made available in the distributed system or that the
resource by its nature can be accessed by at most k processes
simultaneously. 

17. Current Trends
A New Voting-based Mutual Exclusion Algorithm for Distributed Systems – Process holding maximum resources will be given access first
Capturing the system state
Huffman Trees as a Basis for a Dynamic Mutual Exclusion
Bully Election Algorithm in Distributed Systems

18. Future Trends/Own thoughts
Coordinator can be a strongly connected graph of all the processes
as nodes, where a random allocation can be done as soon as the
Co-Ordinator node fails.
Replicated tokens can be used to insure that system works fine incase
of lost token
Combination of Group, local and k-mutual exclusion.

19. References
DISTRIBUTED SYSTEMS Principles and Paradigms Second edition,
Andrew S.Tanenbaum, Maarten Van Steen
A new voting-based mutual exclusion algorithm for distributed systems
Sukhendu Kanrar; Samiran Chattopadhyay; Nabendu Chaki
2013 Nirma University International Conference on Engineering (NUiCONE)
Improved Bully Election Algorithm in Distributed Systems
A.Arghavani E.Ahmadi A.T.Haghighat
Proceedings of the 5th International Conference on
IT & Multimedia at UNITEN (ICIMU 2011) Malaysia

20. Questions?

21. Thank You!