Scribd
Upload
89 views5 pages

Si, I.E. The Set of Sites From Which S N:: Ri (S1, S2,..., SN) - Every Site Si

The document summarizes several distributed mutual exclusion algorithms: 1) Lamport's algorithm uses timestamped request/reply messages and queues to ensure requests are serviced in timestamp order. 2) Ricart-Agrawala improves on Lamport's algorithm by merging release messages into reply messages. 3) Maekawa's algorithm constructs request sets to satisfy specific conditions and uses timestamped request/reply messages.

Uploaded by

thesleeper7
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
89 views5 pages

Si, I.E. The Set of Sites From Which S N:: Ri (S1, S2,..., SN) - Every Site Si

The document summarizes several distributed mutual exclusion algorithms: 1) Lamport's algorithm uses timestamped request/reply messages and queues to ensure requests are serviced in timestamp order. 2) Ricart-Agrawala improves on Lamport's algorithm by merging release messages into reply messages. 3) Maekawa's algorithm constructs request sets to satisfy specific conditions and uses timestamped request/reply messages.

Uploaded by

thesleeper7
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

Lamport's Algorithm

Lamport was the first to give a distributed mutual exclusion algorithm as an


illustration of his clock synchronization scheme. Let Ri be the request set of site
Si , i.e. the set of sites from which Si needs permission when it wants to enter
CS. In Lamport's algorithm, ∀i : 1 ≤ i ≤ N :: Ri= {S1, S2,...,SN}. Every site Si
keeps a queue, request_queuei, which contains mutual exclusion requests
ordered by their timestamps. This algorithm requires messages to be delivered in
the FIFO order between every pair of sites.

The Algorithm

Requesting the critical section.


1. When a site Si wants to enter the CS, it sends REQUEST(tsi, i) message to
all the sites in its request set Ri and places the request on request_queuei (tsi
is the timestamp of the request).
2. When a site Sj receives the REQUEST(tsi, i) message from site Si, it returns
a timestamped REPLY message to Si and places site S'is request on
request_queuej.

Executing the critical section.


1. Site Si enters the CS when the two following conditions hold:
a) [L1:] Si has received a message with timestamp larger than (tsi, i)
from all other sites.
b) [L2:] S'is request is at the top request_queuei.

Releasing the critical section.


1. Site Si, upon exiting the CS, removes its request from the top of its request
queue and sends a timestamped RELEASE message to all the sites in its
request set.
2. When a site Sj receives a RELEASE message from site Si, it removes S'is
request from its request queue.

When a site removes a request from its request queue, its own request
may come at the top of the queue, enabling it to enter CS. The algorithm
executes CS requests in the increasing order of timestamps.
The Ricart-Agrawala Algorithm

The Ricart-Agrawala algorithm is an optimization of Lamport's algorithm that


dispenses with RELEASE messages by cleverly merging them with REPLY
messages. In this algorithm also, ∀i : 1 ≤ i ≤ N : Ri = {S1,S2,...,SN}.

The Algorithm

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 S'is request's timestamp is smaller than Sj's own
request's timestamp. The request is deferred otherwise.

Executing the critical section


1. Site Si enters the CS after it has received REPLY messages from all the sites
in its request set.

Releasing the critical section

1. 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., a smaller timestamp). Thus, when a site sends out
REPLY messages to all the deferred requests, the site with the next highest
priority request receives the last needed REPLY message and enters the CS. The
execution of CS requests in this algorithm is always in the order of their
timestamps.
Maekawa's Algorithm

The Construction of request sets. The request sets for sites in Maekawa's
algorithm are constructed to satisfy the following conditions:
M1: (∀i ∀j : i≠j, 1 ≤ i, j ≤ N :: Ri ∩ Rj ≠ Φ ).
M2: ((∀i : 1 ≤ i ≤ N:: Si ∈ Ri)
M3: (((∀i : 1 ≤ i ≤ N:: |Ri | = K)
M4: Any site Sj is contained in K number of Ris, 1 ≤ i, j ≤ N.

The Algorithm

Requesting the critical section.


1. A site Si requests access to the CS by sending REQUEST(i) messages to all
the sites in its request set Ri.
2. When a site Sj receives the REQUEST(i) message, it sends a REPLY(j)
message to Si provided it hasn't sent a REPLY message to a site from the
time it received the last RELEASE message. Otherwise, it queues up the
REQUEST for later consideration.

Executing the critical section.


1. Site Si accesses the CS only after receiving REPLY messages from all the
sites in Ri.

Releasing the critical section.


1. After the execution of the CS is over, site Si sends RELEASE(i) message to
all the sites in Ri.
2. When a site Sj receives a RELEASE(i) message from site Si, it sends a
REPLY message to the next site waiting in the queue and deletes that entry
from the queue. If the queue is empty, then site updates its state to reflect that
the site has not sent out any REPLY message.
Suzuki-Kasami's broadcast algorithm
The Algorithm

Requesting the critical section


1. If the requesting site Si does not have the token, then it increments its
sequence number, RNi[i], and sends a REQUEST(i, sn) message to all other
sites (sn is the updated value of RNi[i]).
2. When a site Sj receives this message, it sets RNj[i] to max(RNj[i], sn). If Sj
has the idle token, then it sends the token to Si if RNj[i]=LN[i]+1.

Executing the critical section.


1. Site Si executes the CS when it has received the token.

Releasing the critical section. Having finished the execution of the CS, site Si
takes the following actions:
1. It sets LN[i] element of the token array equal to RNi[i].
2. For every site Sj whose ID is not in the token queue, it appends its ID to the
token queue if RNi[j]=LN[j]+1.
3. If token queue is nonempty after the above update, then it deletes the top site
ID from the queue and sends the token to the site indicated by the ID.
Raymond's Tree-Based Algorithm

The Algorithm

Requesting the critical section.


1. When a site wants to enter the CS, it sends a REQUEST message to the node
along the directed path to the root, provided it does not hold the token and its
request_q is empty. It then adds its request to its request_q. (Note that a
nonempty request_q at a site indicates that the site has sent a REQUEST
message to the root node for the top entry in its request_q).
2. When a site recives a REQUEST message, it places the REQUEST in its
request_q and sends a REQUEST message along the directed path to the root
provided it has not sent out a REQUEST message on its outgoing edge (for a
previously received REQUEST on its request_q).
3. When the root site receives a REQUEST message, it sends the token to the
site from which it received the REQUEST message and sets its holder
variable to point at that site.
4. When a site receives the token, it deletes the top entry from its request_q,
sends the token to the site indicated in this entry, and sets its holder variable
to point at that site. If the request_q is nonempty at this point, then the site
sends a REQUEST message to the site which is pointed at by holder variable.

Executing the critical section.


1. A site enters the CS when it receives the token and its own entry is at the top
of its request_q. In this case, the site deletes the top entry from its request_q
and enters the CS.

Releasing the critical section. After a site has finished execution of the CS, it
takes the following actions:
1. If its request_q is nonempty, then it deletes the top entry from its request_q,
sends the token to that site, and sets its holder variable to point at that site.
2. If the request_q is nonempty at this point, then the site sends a REQUEST
message to the site which is pointed at by the holder variable.

You might also like