Mutual Exclusion
• Shared resource(critical region) is
exclusively available to one process at any
given time.
• Semaphores, monitors are used to guarantee
it in uniprocessor system
• In DS it can be achieved using, centralized
or distributed algorithms.
Requirements of Mutual Exclusion
ME1. At most one process in the CS. (Safety property)
ME2. Each process should get a fair chance to execute
(Fairness property)
ME3. Every process trying to enter its CS must eventually succeed.
This is called progress. No deadlock (Liveness property)
the
Progress is quantified by the criterion of bounded waiting. It measures
a form of fairness by answering the question:
CR.
Performance metrics
• Synchronization delay: time interval between CR
exit and new entry by any process.
• System throughput: rate at which requests for the
CR get executed.
• Message complexity: number of messages that are
required per CR execution by a process.
• Response time: time interval from a request send
to its CR execution completed.
Classification of mutual
exclusion algorithms
• Centralized ME algorithms: uses coordinator
• Distributed ME algorithms: do not use centralized
arbitrator
Non-token based: exchange messages among the processes to
determine which process get to enter the CR. When
conditions specified by algorithm are satisfied, only one
process enters the CR at given time is guaranteed.
Token based: a unique token among processes is shared. A
process is allowed to enter its CR, if it possesses the token
and continues to hold until the execution is over.
Centralized algorithm
• All processes in DS require to REQUEST the centralized,
elected ‘coordinator’ to enter the critical region.
• If no other process is currently executing the critical region
that is, variable Grant= F and request Q = E(empty), the
coordinator grants the request to the requesting process by
sending reply message and granting the permission.
• If CR is executed by another process, when request for
permission arrives, this request could be queued by
coordinator or it could reply back permission denied.
Centralized algorithm
• When the process executing the CR exits, It sends a release
message to the coordinator, which prompts the coordinator
to set Grant = F and read the ID of process of deferred
request. The coordinator sends the REPLY message to that
process, sets Grant = T. This message unblocks the process
and now it enters the critical region.
Performance parameters
1. Algorithm is simple and fair
2. Guarantees no starvation
3. Uses three messages as REQUEST,
REPLY and RELEASE.
4. It has a single point of failure
5. Coordinator selection could increase
synchronization delay.
Comments
- Centralized solution is simple.
- But the central server is a single point of failure. This is BAD.
- ME1-ME3 is satisfied, but FIFO fairness is not guaranteed.
Can we do without a central server? Yes!
Distributed mutual exclusion
• It does not use coordinator but uses logical clock for event
ordering.
• The processes coordinate among themselves to guarantee
mutual exclusion.
• A site called control site is assigned the task of granting
permission for the CS execution.
• To request the CS, a site sends a REQUEST message to
the control site.
• The control site queues up the requests for the CS and
grants them permission one by one.
• This method to achieve mutual exclusion in DS requires
only three messages per CS execution.
Distributed mutual exclusion
• Classification
1. Non token based
2. Token based
Distributed mutual exclusion
Non-token based
• These algorithms require two or more successive rounds of
message exchanges among the sites.
• These are assertion based because a site can enter its CS,
when an assertion defined on its local variables becomes
true.
• Mutual exclusion is enforced, because assertion becomes
true only at one site at any one given time.
Distributed mutual exclusion
Token based
• A unique token is shared among the sites.
• A site is allowed to enter its CS if it
possessses the token and it continues to hold
the token until the execution of CS is over
Non-token based
• Lamport’s algorithm
• Ricart Agrawala
• Maekawa
Distributed mutual
exclusion(non-token)
Lamport’s Algorithm
• Lamport was the first to give distributed
mutual exclusion algorithm.
• Every site Si keeps a request queue which
contains mutual exclusion requests ordered
by their timestamps
• This algorithm requires messages to be
delivered in FIFO order between every pair.
Decentralized solution 1
{Lamport’s algorithm}
1. Broadcast a timestamped request to all.
Q0
2. Request received  enqueue it in local Q. Not
in CS  send ack, else postpone sending
ack until exit from CS.
Q1
0
1
2
3
3. Enter CS, when
(i) You are at the “head” of your Q
(ii) You have received ack from all
4. To exit from the CS,
(i) Delete the request from your Q, and
(ii) Broadcast a timestamped release
5. When a process receives a release message,
it removes the sender from its Q.
Q2
Q3
Completely connected topology
Analysis of Lamport’s algorithm
Can you show that it satisfies all the properties
(i.e. ME1, ME2, ME3) of a correct solution?
Q0
Observation. Processes taking a decision to enter
CS must have identical views of their local
queues, when all acks have been received.
Proof of ME1. At most one process can be in its
CS at any time.
Suppose not, and both j,k enter their CS. But
j in CS ⇒ Qj.ts(j) < Qk.ts(k)
k in CS ⇒ Qk.ts(k) < Qj.ts(j)
Impossible.
Q2
Q1
0
1
2
3
Q3
Analysis of Lamport’s algorithm
Proof of ME2. (No deadlock)
The waiting chain is acyclic.
Q0
i waits for j
Q1
0
1
2
3
⇒i is behind j in all queues
(or j is in its CS)
⇒j does not wait for i
Proof of ME3. (progress)
New requests join the end of the
queues, so new requests do not
pass the old ones
Q2
Q3
Analysis of Lamport’s algorithm
Proof of FIFO fairness.
timestamp (j) < timestamp (k)
Req (30)
⇒ j enters its CS before k does so
Suppose not. So, k enters its CS before j. So k
did not receive j’s request. But k received the
ack from j for its own req.
This is impossible if the channels are FIFO
.
Message complexity = 3(N-1) (per trip to CS)
(N-1 requests + N-1 ack + N-1 release)
j
k
Req
(20)
ack
Ricart Agrawala
• This algorithm is an optimization of Lamport’s algorithm
that dispenses with RELEASE messages by merging them
with REPLY messages
• Requesting the critical section
1. When a site Si wants to enter the CS, it sends a
timestamped REQUEST message to all the sites in its
request set.
2. When site Sj receives a REQUEST message from site Si,
it sends a REPLY message to site Si if site Sj is neither
requesting nor executing the CS or if site Sj is requesting
and Si’s request’s timestamp is smaller
Ricart Agrawala
Executing the critical section
3. Site Si enters the CS after it has received REPLY
messages from all the sites in its request set
Releasing the critical section
4. When site Si exits the CS, it sends REPLY messages to all
the deferred requests.
A site’s REPLY messages are blocked only by sites that are
requesting the CS with higher priority.(i.e. smaller
timestamp)
Decentralized algorithm 2
{Ricart & Agrawala’s algorithm}
What is new?
1. Broadcast a timestamped request to all.
2. Upon receiving a request, send ack if
-You do not want to enter your CS, or
-You are trying to enter your CS, but your timestamp is
larger than that of the sender.
(If you are already in CS, then buffer the request)
3. Enter CS, when you receive ack from all.
4. Upon exit from CS, send ack to each
pending request before making a new request.
(No release message is necessary)
Ricart & Agrawala’s algorithm
Message complexity = 2(N-1)
(N-1 requests + N-1 acks - no release message)
Unbounded timestamps
Timestamps grow in an unbounded manner.
This makes real implementations impossible.
Can we somehow bounded timestamps?
Think about it.
Decentralized algorithm 3
{Maekawa’s algorithm}
- First solution with a sublinear O(sqrt N) message
complexity.
- “Close to” Ricart-Agrawala’s solution, but each process
is required to obtain permission from only a subset
of peers
Decentralized algorithm 3
{Maekawa’s algorithm}
Requesting the CS
1. A site si requests access to the CS by sending REQUEST
messages to all he sites in its request set Ri
2. When a site Sj receives the REQUEST(i) message, it sends a
REPLY(j) to Si provided it has not sent a REPLY msg to a
site from the time it received the last RELEASE msg.
Decentralized algorithm 3
{Maekawa’s algorithm}
Executing CS
3. SITE Si accesses the CS only after receiving REPLY msg from
all the sites in Ri.
Releasing the CS
4 After the execution of CS over, site Si sends RELEASE msg to
all sites in Ri
5 When site Sj receives RELEASE msg from site Si, it sends a
REPLY msg to next site waiting in Q and deletes that entry
from Q. If Q is empty then site updates its state to reflect that
site has not sent out any REPLY msg
Decentralized algorithm 3
{Maekawa’s algorithm}
This algorithm requires extra messages to handle
deadlocks and may exchange these messages when
there is no deadlock. The maximum no. of messages
required per CS execution in this case is 5 *sqrt( N )
Maekawa’s algorithm-Version 2
0
0
6
1
ack
18
req
5
4
12
req
6
1
25
req
2
inquire
5
18
2
12
3
failed
4
3
Token-passing Algorithms for
mutual exclusion
Suzuki-Kasami algorithm
The Main idea
Completely connected network of processes
There is one token in the network. The holder
of the token has the permission to enter CS.
Any other process trying to enter CS must
acquire that token. Thus the token will move
from one process to another based on
demand.
I want to enter CS
I want to enter CS
Suzuki-Kasami Algorithm
req
Process i broadcasts (i, num)
req
Sequence number
of the request
queue Q
Each process maintains
-an array req: req[j] denotes the sequence
no of the latest request from process j
(Some requests will be stale soon)
Additionally, the holder of the token maintains
-an array last: last[j] denotes the
sequence number of the latest visit to CS
for process j.
- a queue Q of waiting processes
last
req
req
req
req: array[0..n-1] of integer
last: array [0..n-1] of integer
Suzuki-Kasami Algorithm
When a process i receives a request (k, num) from
process k, it sets req[k] to max(req[k], num).
The holder of the token
--Completes its CS
--Sets last[i]:= its own num
--Updates Q by retaining each process k only if
1+ last[k] = req[k]
(This guarantees the freshness of the request)
--Sends the token to the head of Q, along with
the array last and the tail of Q
Req: array[0..n-1] of integer
Last: Array [0..n-1] of integer
In fact, token ≡ (Q, last)
Example
req=[1,0,0,0,0]
req=[1,0,0,0,0]
last=[0,0,0,0,0]
1
0
2
req=[1,0,0,0,0]
4
req=[1,0,0,0,0]
3
req=[1,0,0,0,0]
initial state: process 0 has sent a request to
all, and grabbed the token
Example
req=[1,1,1,0,0]
req=[1,1,1,0,0]
last=[0,0,0,0,0]
1
0
2
req=[1,1,1,0,0]
4
req=[1,1,1,0,0]
3
req=[1,1,1,0,0]
1 & 2 send requests to enter CS
Example
req=[1,1,1,0,0]
req=[1,1,1,0,0]
last=[1,0,0,0,0]
Q=(1,2)
0
1
2
req=[1,1,1,0,0]
4
req=[1,1,1,0,0]
3
req=[1,1,1,0,0]
0 prepares to exit CS
Example
req=[1,1,1,0,0]
1
0
req=[1,1,1,0,0]
last=[1,0,0,0,0]
Q=(2)
2
req=[1,1,1,0,0]
4
req=[1,1,1,0,0]
3
req=[1,1,1,0,0]
0 passes token (Q and last) to 1
Example
req=[2,1,1,1,0]
1
0
req=[2,1,1,1,0]
last=[1,0,0,0,0]
Q=(2,0,3)
2
req=[2,1,1,1,0]
4
req=[2,1,1,1,0]
3
req=[2,1,1,1,0]
0 and 3 send requests
Example
req=[2,1,1,1,0]
req=[2,1,1,1,0]
1
0
2
4
req=[2,1,1,1,0]
3
req=[2,1,1,1,0]
last=[1,1,0,0,0]
Q=(0,3)
req=[2,1,1,1,0]
1 sends token to 2
Raymond’s tree-based algorithm
3
1
2
1
4
5
4
1
6
1,4
7
4,7
1,4,7 want to enter their CS
Raymond’s Algorithm
3
1
2
1
4
5
4
6
1,4
7
4,7
2 sends the token to 6
Raymond’s Algorithm
3
These two directed edges will
reverse their direction
1
2
6
4
7
4
4
4
5
4,7
6 forwards the token to 1
The message complexity is O(diameter) of the tree. Extensive
empirical measurements show that the average diameter of randomly
chosen trees of size n is O(log n). Therefore, the authors claim that the
average message complexity is O(log n)