1. Chapter 6.3 Mutual Exclusion
CSc Advanced Operating Systems
Berkay Aydin
September 23rd, 2015

2. Mutual Exclusion FUNDAMENTALS PART I FUNDAMENTALS Contents
Introduction
Centralized Algorithm
Decentralized Algorithm
Distributed Algorithm
Token Ring Algorithm
Summary and Comparison
Mutual Exclusion
PART I
FUNDAMENTALS

3. Introduction Fundamental aspect of distributed systems
Concurrency and collaboration among multiple processes
Simultaneous access
Prevention of corruption and inconsistency of resources
Mutual exclusion
Distributed algorithms
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

4. Overview Centralized Algorithm Decentralized Algorithm
Distributed Algorithm
Token Ring Algorithm
Summary and Comparison

5. Centralized Algorithm
FUNDAMENTALS
Contents
Introduction
Centralized Algorithm
Decentralized Algorithm
Distributed Algorithm
Token Ring Algorithm
Summary and Comparison

6. Centralized Algorithm
Straightforward
Simulation of a one-processor system
One process is elected as the coordinator
A queue is used for requests
Controlled by the coordinator
Easy to implement
request, grant, release

7. Centralized Algorithm
Method
Select a coordinator
For accessing a shared resource, ask permission from coordinator (request)
If resource is not used, coordinator gives permission (grant)
Else coordinator moves the request to the queue
It can send a message for denying the permission
Wait till the resource is available
When finished using the resource, send a message to coordinator for releasing the resource (release)

8. Centralized Algorithm
Image taken from (Tannenbaum&Steen, 2006)

9. Centralized Algorithm
Advantages
Easy to implement
Processes do not wait forever (no starvation)
Disadvantages
Coordinator is single point of failure
Single coordinator can be a performance bottleneck

10. Decentralized Algorithm
FUNDAMENTALS
Contents
Introduction
Centralized Algorithm
Decentralized Algorithm
Distributed Algorithm
Token Ring Algorithm
Summary and Comparison

11. Decentralized Algorithm
Voting algorithm
DHT-based algorithm
Resource is replicated n times, and each resource has its own coordinator
When needed access, a majority vote from coordinator shall be granted for accepting the request

12. Decentralized Algorithm
Method
n replicas of a resource has n coordinators
All processes (clients) that want to access a resource send requests to each coordinator
A coordinator grants a permission (lease) if it is not owned by anyone
If it is owned, it sends a reject back to the client
The process (client) who got the majority vote (m >n/2) gets the permission
The other processes who lost the vote
Release the acquired votes
Retry after a random period of time

13. Decentralized Algorithm
Possible shortcomings of the method
Random reset may cause a coordinator to have a change of heart -
Therefore, breaking the mutual exclusion
Image taken from (Lin et al., 2004)

14. Decentralized Algorithm
Possible shortcomings of the method
Performance of the protocol drops when many clients want to access same resource.
Nobody gets the majority vote, and utilization drops
Image taken from (Lin et al., 2004)

15. Distributed Algorithm
FUNDAMENTALS
Contents
Introduction
Centralized Algorithm
Decentralized Algorithm
Distributed Algorithm
Token Ring Algorithm
Summary and Comparison

16. Distributed Algorithm
Deterministic distributed mutual exclusion algorithm
Requires total ordering (unambiguous) of all events in the system
When a process wants to access a resource
It builds a message containing: name of the resource, process number, current time
Message sending assumed to be reliable

17. Distributed Algorithm
Method
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 -> It sends OK
If receiver already has access -> It queues the message
If receiver also wants to access, but not yet done so -> It controls the time of the received message with the one that it had sent to others
If receiver’s timestamp is larger -> It sends back OK
Else it queues the message

18. Distributed Algorithm
Image taken from (Tannenbaum&Steen, 2006)
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.

19. Distributed Algorithm
Disadvantages
n point of failures
Group membership must be maintained
All processes are involved in all decisions, bottleneck
Improvements
Point of failure - sender time out
Majority vote for access

20. FUNDAMENTALS Contents Token Ring Algorithm Introduction
Centralized Algorithm
Decentralized Algorithm
Distributed Algorithm
Token Ring Algorithm
Summary and Comparison

21. Token Ring Algorithm Ring configuration
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
No starvation, but detecting a lost token is expensive
Image taken from (Tannenbaum&Steen, 2006)

22. Summary and Comparison
FUNDAMENTALS
Contents
Introduction
Centralized Algorithm
Decentralized Algorithm
Distributed Algorithm
Token Ring Algorithm
Summary and Comparison

23. Summary and Comparison
MESSAGES PER ENTRY
The centralized algorithm is simplest and also most efficient. It requires only
three messages to enter and leave a critical region: a request, a grant to enter, and
a release to exit. In the decentralized case, we see that these messages need to be
carried out for each of the m coordinators, but now it is possible that several
attempts need to be made (for which we introduce the variable k). The distributed
algorithm requires n - 1 request messages, one to each of the other processes, and
an additional n - 1 grant messages, for a total of 2(n- 1). (We assume that only
point-to-point communication channels are used.) With the token ring algorithm,
the number is variable. If every process constantly wants to enter a critical region.
then each token pass will result in one entry and exit, for an average of one mes-
sage per critical region entered.
DELAY before ENTRY
The delay from the moment a process needs to enter a critical region until its
actual entry also varies for the three algorithms. When the time using a resource is
short, the dominant factor in the delay is the actual mechanism for accessing a re-
source. When resources are used for a long time period, the dominant factor is
waiting for everyone else to take their tum. In Fig we show the former case.
It takes only two message times to enter a critical region in the centralized case,
but 3mk times for the decentralized case, where k is the number of attempts that
need to be made. Assuming that messages are sent one after the other, 2(n - 1)
message times are needed in the distributed case. For the token ring, the time
varies from 0 (token just arrived) to n - 1 (token just departed).
Problems
Finally, all algorithms except the decentralized one suffer badly in the event
of crashes. Special measures and additional complexity must be introduced to
avoid having a crash bring down the entire system. It is ironic that the distributed
algorithms are even more sensitive to crashes than the centralized one. In a system
that is designed to be fault tolerant, none of these would be suitable, but if crashes
are very infrequent, they might do. The decentralized algorithm is less sensitive to
crashes, but processes may suffer from starvation and special measures are needed
to guarantee efficiency.
Image taken from (Tannenbaum&Steen, 2006)

24. Group Mutual Exclusion
CURRENT WORK
Contents
Group Mutual Exclusion
Local Mutual Exclusion
Mutual Exclusion
PART II
CURRENT WORK

25. Group Mutual Exclusion
Each critical section (CS) has a type (or group)
Processes requesting critical sections
belonging the same group may execute their critical sections concurrently
belonging to different group must execute in a mutually exclusive way

26. Group Mutual Exclusion
Example: Multiple Reader/Single Writer (MRSW) problem
Let n be the number of processes -> n+1 groups
All read-critical sections belong to the same group
All write-critical sections belong to different groups
Example: Disk jukebox
CDs can only be loaded one at a time. Processes can read from same CD when CD is loaded, others have to wait.

27. Group Mutual Exclusion
Many algorithms are presented for the solution of GME
Jayanti et al. (2003) - Fair Group Mutual Exclusion problem
Mittal and Mohan (2007) - Group Mutual Exclusion when the access is not uniform (Priority-based)

28. CURRENT WORK Contents Group Mutual Exclusion Local Mutual Exclusion

29. Group Mutual Exclusion
Each critical section (CS) has a type (or group)
Processes requesting critical sections
belonging the same group may execute their critical sections concurrently
belonging to different group must execute in a mutually exclusive way

30. Group Mutual Exclusion
Example: Multiple Reader/Single Writer (MRSW) problem
Let n be the number of processes -> n+1 groups
All read-critical sections belong to the same group
All write-critical sections belong to different groups
Example: Disk jukebox
CDs can only be loaded one at a time. Processes can read from same CD when CD is loaded, others have to wait.

31. Local Mutual Exclusion
Local mutual exclusion ensures that critical sections of neighboring nodes must be executed in exclusion with its neighbors (Attiya et al., 2010)
Less restrictive than general mutual exclusion problem
For mobile ad hoc networks (data collection from a particular region)
Locality of a failure is important

32. PART III TRENDS AND FUTURE WORK
Contents
Trends
A Futuristic Scenario
Mutual Exclusion
PART III
TRENDS AND FUTURE WORK

33. Trends Combinations of mutual exclusion concepts
Local Mutual Exclusion
Group Mutual Exclusion
k-Mutual Exclusion
Local-Group, k-Local etc.
Trend is to introduce a useful property such as, proximity, fault tolerance, selecting leaders etc.

34. Problem
Solving the mutual exclusion for only a certain group of tasks and creating a self-correcting system
Read-Write conflicts requires the need for mutual exclusiveness. The self-correcting system should have following properties:
Logs every access and update
Commands the affected nodes to return back to their previous state, or recovers them from their situation
Returns back and corrects the all nodes

35. Example Credit card account - Balance is -$100
The interest rate is %10 and owner pays $100 just before the interest is applied. If not paid on time the credit card is blocked.
The updates (logged and applied, in order) are:
Balance <- Balance + 100
if(Balance < 0) then Balance <- Balance * 1.1
if (Balance < 0) then Block the card

36. Example
When no mutual exclusion is enforced, B can be done before A; therefore creating a problem.
The correcting system should be able to log everything and update when operations are not performed in order.
Meaning, it should go back to initial state where balance is -$100; and update all the system accordingly
This update should be frequent enough that no real effects should be observed in the real life

37. References
Attiya, H., Kogan, A., & Welch, J. L. (2010). Efficient and robust local mutual exclusion in mobile ad hoc networks. Mobile Computing, IEEE Transactions on,9(3),
Jayanti, Prasad, Srdjan Petrovic, and King Tan. "Fair group mutual exclusion."Proceedings of the twenty-second annual symposium on Principles of distributed computing. ACM, 2003.
Lin, S. D., Lian, Q., Chen, M., & Zhang, Z. (2005). A practical distributed mutual exclusion protocol in dynamic peer-to-peer systems. In Peer-to-Peer Systems III (pp ). Springer Berlin Heidelberg.
Mittal, N., & Mohan, P. K. (2007). A priority-based distributed group mutual exclusion algorithm when group access is non-uniform. Journal of parallel and distributed computing, 67(7),
van Steen, M., & Tanenbaum, A. (2001). Distributed Systems, Principles and Paradigms. Vrije Universiteit Amsterdam, Holland, 1-2.