1. Mutual Exclusion Algorithms

2. Topics r Defining mutual exclusion r A centralized approach r A distributed approach r An approach assuming an organization of processes as a ring

3. Readings r Van Steen and Tanenbaum: 5.5 r Coulouris: 11.2

4. Mutual Exclusion r If a collection of processes share a resource or collection of resources, then often mutual exclusion is required to prevent interference and ensure consistency when accessing the resources. r You first saw this concept in CS 305 m Concurrent processes (or threads) often need to share data (maintained in either shared memory or files) or resources. m With no synchronization results may not be reproducible or deterministic.

5. Mutual Exclusion r Example: Consider users updating a file. m To ensure update are consistent, allow users to access it only one at a time by requiring the editor to lock the file before updates can be made. m UNIX systems provide a separate file-locking service, implemented by the daemon lockd to handle locking requests from clients. Example: Peer access to a shared resource m Ethernet and IEEE 801.11 wireless networks r Example: Access to Printer

6. Requirements r Safety: At most one process in critical section at any time. r Freedom from deadlock: two or more processes stuck indefinitely while attempting to enter or exit the critical section r Freedom from starvation: If some process requests to use the critical section then eventually it will be able to.

7. Mutual Exclusion: A Centralized Algorithm 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

8. Mutual Exclusion: A Centralized Algorithm r Shortcomings m The coordinator is a single point of failure, so if it crashes, the entire system may go down. Wait; why not just elect another coordinator? You can. The only concern is figuring out who has access to the critical section. How do you tell the difference between a dead coordinator and “permission denied”? m In a large system a single coordinator may become a performance bottleneck.

9. Mutual Exclusion: A Centralized Algorithm r Number of message needed m 3 messages to enter and leave a critical region: A request A grant to enter A release to exit.

10. Mutual Exclusion: A Distributed Algorithm r Process requests that it wants to enter a critical region by creating a message with this info: m Name of the critical region it wants to enter m Its process number m The current time (as determined by Lamport’s clocks). r Message is sent to all other processes including itself. r Assume messages are delivered reliably.

11. Mutual Exclusion: A Distributed Algorithm r Upon receipt of a message, a process needs to distinguish these three cases: 1. If the receiver is not in the critical region and does not want to enter it, it sends back an OK message to the sender. 2. If the receiver is already in the critical region, it does not reply. Instead, it queues the request. 3. If the receiver wants to enter the critical region but has not done so, it compares the timestamp (generated using Lamport’s clocks (extended for total order)) in the incoming message with the one contained in the message that it has sent everyone. The lowest wins. If the incoming message is lower, the receiver sends back an OK message else it queues the incoming request and sends nothing.

12. Mutual Exclusion: A Distributed Algorithm r After sending out requests asking permission to enter a critical region, a process sits back and waits until everyone else has given permission. r After all the permissions are in, it may enter the critical region. r When it exits the critical region it sends OK messages to all processes on its queue.

13. Mutual Exclusion: A Distributed Algorithm Events a,e are requests for critical region access For P1, event b is P2’s request; For P2, event f is P1’s request For P3, event j is P1’s request and event k is P2’s request P1P2 P3 b e f k j a

14. Mutual Exclusion: A Distributed Algorithm Event l in P3 is associated with P3 sending OK to P2 and P1 b P1 c P2 e f g P3 k j l a

15. Mutual Exclusion: A Distributed Algorithm b P1 c d P2 e f g h P3 k j l a Event h is P2 sending an OK to P1 since P1 has a lower identifier; Event d in P1 is the receipt of the OK from P2. P1 can now enter the critical section.

16. Mutual Exclusion: A Distributed Algorithm b P1 c d P2 e f g h P3 k j l a Event i in P1 sends an OK to P2 when it finishes with the critical section. i j

17. Mutual Exclusion: A Distributed Algorithm r The algorithm presented is the simplest case. r You may want to multicast OKs to all processes.

18. Mutual Exclusion: A Distributed Algorithm r The single point of failure has been replaced by n points of failure. r If any process crashes, it will fail to respond to requests. What is the difference between a denial and a dead process?

19. Mutual Exclusion: A Distributed Algorithm r How to deal with this? m When a request comes in, the receiver always sends a reply, either granting or denying permission. m Whenever 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. m After a request is denied, the sender should block waiting for a subsequent OK message. Who is going to send it? m Not easy to deal with this!

20. Mutual Exclusion: A Distributed Algorithm r Number of messages needed m Entering a critical section n-1 request messages n-1 grant messages Total: 2(n-1)

21. Mutual Exclusion: A Token Ring Algorithm a) An unordered group of processes on a network. b) A logical ring constructed in software.

22. Mutual Exclusion: A Token Ring Algorithm r When the ring is initialized, process 0 is given a token. r The token circulates around the ring. r It is passed from process k to process k+1. r When a process acquires the token from its neighbor it checks to see if it is attempting to enter a critical region. r If so, the process enters the region, does all the work it needs to and leaves the region. r Token is passed to the next process in the ring.

23. Mutual Exclusion: A Token Ring Algorithm r Shortcomings m If the token is lost, it must be regenerated. m Very difficult to determine if a token is lost since a process may be in a critical section for a long time. m If there is a crash, recovery is easier than in other cases. If we require a process receiving the token to acknowledge receipt, a dead process will be detected when its neighbor tries to give it the token and fails. The token is passed to the successor of the dead process. This requires that each process knows the ring configuration.

24. Mutual Exclusion: A Token Ring Algorithm r Number of messages needed m Variable number of messages needed m If every process constantly wants to enter a critical region, then each token pass will result in one entry and one exit. m The token may circulate for hours without anyone being interested in it. In this case, the number of messages per entry into a critical region is unbounded. m We note that there is delay in from the moment a process needs to enter a critical region until its actual entry. If the token just left, it needs to wait until the token has gone through the n-1 nodes. If the token just arrived, there is no wait.

25. Summary r All three algorithms suffer badly in event of crashes. r Special measures and additional complexity must be introduced to avoid having a crash bring down the entire system.