CSC 8320 4.5 Distributed Mutual Exclusion. Presenter: Weiling Li Instructor: Dr. Zhang. Overview. Part I: Basic Knowledge [1,2,3] * Contention-based Mutual Exclusion * Token-based Mutual Exclusion Part II: Current Research * Hybrid Distributed Mutual Exclusion
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Presenter: Weiling Li
Instructor: Dr. Zhang
* Contention-based Mutual Exclusion
* Token-based Mutual Exclusion
* Hybrid Distributed Mutual Exclusion
* Use Multicast in Distributed Mutual Exclusion Algorithms for Grid File Systems 
* The Weak Mutual Exclusion problem 
* usually do not need synchronization.
* multiple clients make service request to a shared server.
* Co-ordination: there is no explicit interaction among client process.
* Intercrosses communication: oftentimes processes need to exchange information to reach some conclusion about the system or some agreement among the cooperating processes.
* there is no shared object or centralized controller.
The total message count is 3*(N-1), where N is the
number of cooperating processes.
Improvement: Number of network messages is 2*(N-1)
Disadvantage: 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.
O(N) messages per request.
Possibility of deadlock.
Any process retrieves its REPLY message by sending an INQUIRY if the requestor is not currently executing in the critical section. The Requestor has to return the vote through a RELINQUISH message.
- simple, deadlock-free, and fair.
- Token can also carry state information.
-The token circulates even in the absence of any request (unnecessary traffic).
-Long path (O(N)) – the wait for token may be high.
If not Tokenholder
If the request queue empty
request token from parent;
put itself in request queue;
block self until Tokenholder is true;
parent = dequeue(request queue);
send token to parent;
set Tokenholder to false;
if the request queue is still not empty, request token from parent;
If in critical section put the requestor in the queue
parent = requestor;
Tokenholder = false;
send token to parent;
elseif the queue is empty
send a request to the parent;
put the requestor in queue;
Upon receipt of a token:
Parent = Dequeue(request queue);
if self is the parent
send token to the parent;
if the queue is not emptyrequest token from parent;
The token contains
* Token vector T(.) –number of completions of the critical sectionfor 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.
Entry Section (process i):
Exit Section (process i):
Processing a REQUEST (process j):
Disadvantage: Requires broadcast. Therefore message
overhead is high.
Volume 7 , Issue 1 ,February 1989.
Parallel & Distributed Processing, 2009. IPDPS 2009. IEEE International Symposium on 23-29 May 2009 Page(s):1 - 12