Distributed Mutual Exclusion

1. Distributed Mutual Exclusion Fall 2007 Himanshu Bajpai hbajpai1@student.gsu.edu

2. Overview • Distributed Mutual Exclusion • Contention-based Mutual Exclusion • Timestamp Prioritized Schemes • Voting Schemes • Token-based Mutual Exclusion • Ring Structure • Tree Structure • Broadcast Structure

3. Preview [Randy Chow ’98] There are three major communication scenarios: One-way, client/server, and peer communication. One-way communication usually do not need synchronization. Client/server communication is for multiple clients making service request to a shared server. If co-ordination is required among the clients, it is handled by the server and

4. Contd.. there is no explicit interaction among client process. But, intercrosses communication is just not limited to making service requests. Oftentimes processes need to exchange information to reach some conclusion about the system or some agreement among the cooperating processes.

5. Contd.. These activities require peer communication; there is no shared object or centralized controller.

6. Distributed Mutual Exclusion [Randy Chow ’98] Mutual exclusion (often abbreviated to mutex) ensures that concurrent processes make a serialized access to shared resources or data (e.g., updating a database or sending control signals to an I/O device).

7. Contd… A distributed mutual exclusion algorithm achieves mutual exclusion using only peer communication. The problem can be solved using either a contention-based or a token-based approach.

8. Contention-based Mutual Exclusion[2] A contention-based approach means that each process freely and equally competes for the right to use shared resource by using a request resolution criteria. The resolution criteria may be based on the times of requests, priorities of the requesters, or voting.

9. Contd.. Contention for the critical section can be resolved by any criteria for braking ties when simultaneous request occurs. The fairest way is to grant the request to the process which asked first (in logical time) or the process which got the most votes from the other processes. We will call these two different approaches timestamp prioritized and voting schemes.

10. Timestamp Prioritized Schemes Approach due to Lamport.  These are the general properties for the method: • The general mechanism is for a process P[i]  to send a request ( with ID and time stamp ) to all other processes. • When a process P[j] receives such a request, it may reply immediately or it may defer sending a reply back.

11. Contd.. • When responses are received from all processes, then P[i] can enter its Critical Section. • When P[i] exits its critical section, the process sends reply messages to all its deferred requests. The total message count is 3*(N-1), where N is the number of cooperating processes.

12. Ricart and Agrawala algo..[1] Requesting Site: • A requesting site Pi sends a message request(ts,i) to all sites. Receiving Site: • Upon reception of a request(ts,i) message, the receiving site Pj will immediately send a timestamped reply(ts,j) message if and only if: • Pj is not requesting or executing the critical section OR • Pj is requesting the critical section but sent a request with a higher timestamp than the timestamp of Pi • Otherwise, Pj will defer the reply message.

13. Contd.. Critical Section: • Site Pi enters its critical section only after receiving all reply messages. • Upon exiting the critical section, Pi sends all deferred reply messages. Performance • Number of network messages; 2*(N-1) • Synchronization Delays: One message propagation delay

14. Contd.. Common Optimizations • Once site Pi has received a reply message from site Pj, site Pi may enter the critical section without receiving permission from Pj until Pi has sent a reply message to Pj Problems • One of the problems in this algorithm is failure of a node. In such a situation a process may starve forever. This problem can be solved by detecting failure of nodes after some timeout.

15. Voting Schemes [2] Requestor: • Send a request to all other process. • Enter critical section once REPLY from a majority is received • Broadcast RELEASE upon exit from the critical section. Other processes: • REPLY to a request if no REPLY has been sent. Otherwise, hold the request in a queue. • If a REPLY has been sent, do not send another REPLY till the RELEASE is received.

16. Contd.. Observations: • No single point of failure, but possibility of deadlock. • O(N) messages per request.

17. Voting Scheme (Improved-1) Requestor: • Send a request with time stamp to all other process. • Enter critical section once REPLY from a majority is received • Return the REPLY message upon receipt of an INQUIRY if not currently executing in the critical section. • Broadcast RELEASE upon exit from the critical section.

18. Contd.. Other processes: • If no REPLY has been sent, REPLY to any REQUEST. • If a REPLY has been sent but the RELEASE has not been received, compare the time stamp of the new REQUEST with the time stamp of the replied REQUEST. If the new REQUEST has an earlier time stamp, try to retract the old REPLY sending INQUIRY message. If the older REPLY is returned, send REPLY to the new REQUEST. Otherwise, wait for the RELEASE.

19. Contd.. Observation: • High (O(N)) messages per critical section entry.

20. Token-based Mutual Exclusion[3] Although contention-based distributed mutual exclusion algorithms can have attractive properties, their messaging overhead is high. An alternative to contention-based algorithms is to use an explicit control token, possession of which grant access to the critical section.

21. Contd.. If there is only one token mutual exclusion is assured. Different methods for requesting and passing the token give different performance and fairness properties. To ensure that a request gets routed to the token holder and the token routed to the requester, algorithms impose a logical structure on the processes.

22. Ring Structure A completely different approach to achieving mutual exclusion in a distributed system is illustrated in Fig. Here we have a bus network, as shown in Fig. a, (e.g., Ethernet), with no inherent ordering of the processes. In software, a logical ring is constructed in which each process is assigned a position in the ring, as shown in Fig. b. The ring positions may be allocated in numerical order of network addresses or some other means. It does not matter what the ordering is. All that matters is that each process knows who is next in line after itself.

23. Contd..

24. Contd… • simple, deadlock-free, fair. • The token circulates even in the absence  of any request (unnecessary traffic). • Long path (O(N)) – the wait for token may  be high.

25. Tree Structure [3;5] • The processes are organized in a logical tree structure, each node pointing to its parent. • Further, each node maintains a FIFO list of token requesting neighbors. • Each node has a variable Tokenholder initialized to false for everybody except for the first token holder (token generator).  

26. Contd..

27. Contd.. Entry section: • If not Tokenholder • If the request queue empty • request token from parent; • put itself in request queue; • block self until Tokenholder is true;

28. Contd.. Exit section: • If the request queue is not empty     parent = dequeue(request queue);     send token to parent;      set Tokenholder to false;      if the request queue is still not empty, request token from parent;

29. Contd.. Upon receipt of a request: • If Tokenholder        If in critical section put the requestor in the queue  else            parent = requestor; Tokenholder = false; send token to parent;  endif                else           if the queue is empty       send a request to the parent;                                     put the requestor in queue;

30. Contd.. Upon receipt of a token: • Parent = Dequeue(request queue);                   if self is the parent Tokenholder= true else         send token to the parent;      if the queue is not empty       request token from parent; 

31. Broadcast Structure Data Structure: The token contains        Token vector T(.) – number of completion of the critical section for every process.    Request queue Q(.) – queue of requesting processes. Every process (i) maintains the following      seq_no – how many times i requested critical section.   Si(.) – the highest sequence number from every process i heard of.

32. Contd.. Entry Section (process i): • Broadcast a REQUEST message stamped with seq_no. • Enter critical section after receiving token.

33. Contd.. Exit Section (process i): • Update the token vector T by setting T(i) to Si(i). • If process k is not in request queue Q and there are pending requests from k (Si(k)>T(k)), append process k to Q. • If Q is non-empty, remove the first entry from Q and send the token to the process indicated by the top entry.

34. Contd.. Processing a REQUEST (process j): • Set Sj(k) to max(Sj(k), seq_no) after receiving a REQUEST from process k. • If holds an idle token, send it to k.  Requires broadcast. Therefore message overhead is high.

35. References 1. http://en.wikipedia.org/wiki/Ricart-Agrawala_algorithm • Author “Jerry Breecher ” http://209.85.165.104/search?q=cache:-jmGub2By8EJ:cs.clarku.edu/~jbreecher/os/lectures/Section18-Distributed_Coordination.ppt+timestamp+prioritized+schemes+request+reply+release+method&hl=en&ct=clnk&cd=1&gl=us 3. Author “Rajgopal Kannan” http://209.85.165.104/search?q=cache:lwcn54j5W_MJ:bit.csc.lsu.edu/~rkannan/rk7103_chpt4.ppt+Voting+schemes+method+in+contention+based+mutual+exclusion&hl=en&ct=clnk&cd=3&gl=us

36. Contd.. 4. Distributed operating systems & Algorithms, By Randy chow, Theodore Johnson. 1998 5. Author = “Kerry Raymond” 1989 http://delivery.acm.org/10.1145/60000/59295/p61-raymond.pdf?key1=59295&key2=1979241911&coll=GUIDE&dl=GUIDE&CFID=1528714&CFTOKEN=58116800