D ISTRIBUTED S YSTEM M UTUAL E XCLUSION UNIT-3. D ISTRIBUTED M UTUAL E XCLUSION Concurrent access to a shared resource (critical region) by several

DISTRIBUTED SYSTEM

MUTUAL EXCLUSIONUNIT-3

DISTRIBUTED MUTUAL EXCLUSION Concurrent access to a shared resource (critical region) by

several uncoordinated processes located on several sites is serialized to secure the integrity of the shared resource.

The major differences comparing with the single processor ME problem are: (1) there is no shared memory and (2) there is no common physical clock.

Classification of Mutual Exclusion algorithms

Non-Token based algorithms

Token based algorithms

Requirements of Distributed ME

Mutual Exclusion: guarantee that only one request access the CR at a time.

Freedom from deadlock: two or more sites(hosts) should not endlessly wait for msg’s that will never arrive.

Freedom from starvation: a site should not be forced to wait indefinitely to access CR.

Fairness: requests must be executed in the order they are made. (fairness freedom of starvation, but not reverse)

Fault tolerance: in the case of failure, the algorithm can reorganize itself so that it continues to function without any disruption.

HOW TO MEASURE THE PERFORMANCE

Number of messages necessary per CS invocation The synchronization delay

Response Time

The system throughput = 1 / ( sd + E ) sd : synchronization delay E: Average critical section execution time

SOLUTION TO MUTUAL EXCLUSION

There are three different approach for solution to Mutual Exclusion in distributed system

Centralize Approach Distributed Approach Token Ring Approach

Centralized Solution

Queue up the requests and grant CR one by one.

Cp2

p1

p3

3 msg’s per CR invocation: REQ, ACK, REL Single point of failure Control site is a bottleneck SD = 2T where T is the communication delay ST = 1/(2T + E)

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, when then replies to process 2.

As shown in figure a), the coordinator is not reply to process 2 when the critical region is occupied. Here, depending on the type of system, the coordinator can also reply back to the process 2 that it is in queue. If the coordinator doesn’t do so, then the waiting process 2 will be unable to distinguish between ‘permission denied” or a “dead” coordinator.

This type of system as a single point of failure, if the coordinator fails, then the entire system crashes.

DISTRIBUTED ALGORITHM

The processes communicate by using messages

only and there is no global controller.

When a process wants to enter a critical region, it builds a message containing: name of the critical region it’s process number it’s current time.

DISTIBUTED ALGORITHM (CONTD…)

The process sends this message to all the processes in the network. When another process receives this message, it takes the action pertaining on its state and the critical region mentioned. Three cases are possible here:

1) If the message receiving process is not in the critical region and does not wish to enter it, it sends it back.

2) Receiver is already in the critical region and does not reply

3) Receiver wants to enter the same critical region and a

4) Has not done so, it compares the “time stamp” of the incoming message with the one it has sent to others for permission. The lowest one wins and can enter the critical region.

When the process exists from the critical region, it sends an

OK message to inform everyone

DISTIBUTED ALGORITHM (CONTD…)

a) Two processes want to enter the same critical region atthe same moment.b) Process 0 has the lowest timestamp, so it wins.c) When process 0 is done, it sends an OK also, so 2 cannow enter the critical region.

TOKEN RING ALGORITHM: a logical ring is constructed in which each process is assigned

a position in the ring. The ring positions may be allocated in numerical order of network addresses or some other means.

When the ring is initialized, process 0 is given a token. The

token circulates around the ring. It is passed from process k

to process k +1 in point-to-point messages. When a process acquires the token from its neighbour, it

checks to see if it is attempting to enter a critical region. If so, the process enters the region, does all the work it needs to, and leaves the region. After it has exited, it passes the token along the ring.

It is not permitted to enter a second critical region using the same token. If a process is handed the token by its neighbour and is not interested in entering a critical region,it just passes it along.

As a consequence, when no processes want to enter any critical regions, the token just circulates at high speed around the ring.

TOKEN RING ALGORITHM (CONTD….)

a) An unordered group of processes on a network.b) A logical ring constructed in software.

NON TOKEN BASED ALGORITHMS Lamport’s Algorithm for mutual exclusion: For all i: 1<=i<=N::Ri = {S1, S2,….SN }

Every site Si keeps a queue : request_queuei, contains mutual exclusion requests ordered by their timestamps

.

LAMPORT’S ALGORITHM FOR MUTUAL EXCLUSION

Requesting the critical section:

1. When a site Si wants to enter the CS, it sends a

REQUEST(tsi , i) message to all the sites in its request

set Ri and places the request on request_queuei.

2. When a site Sj receives the REQUEST(tsi , i ) message

from site Si ,places site it returns a time stamped REPLY

message to Si and places site Si ’s request on

request_queuej.

LAMPORT’S MUTUAL EXCLUSION ALGO….

Executing the critical section: Site Si enters the CS when the following two

conditions hold:

L1: Si has received a message with timestamp larger than (tsi , i ) from all other sites.

L2: Si ’s request is at the top of request queuei .

LAMPORT’S MUTUAL EXCLUSION ALGO….

Releasing the critical section:

3. Site Si , upon exiting the CS, removes its request from

the top of its request queue and broadcasts a

timestamped RELEASE message to all other sites.

4. When a site Sj receives a RELEASE message from site

Si , it removes Si ’s 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 the CS.

RICART-AGRAWALA 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 the site Sj receives 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

than site Sj’s own request’s timestamp. The request

is differed otherwise.

RICART-AGRAWALA ALGORITHM CONTD…

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.

MAEKAWA’S ALGORITHM FOR MUTUAL EXCLUSION

To get access to a CS, not all processes have to agree

Split set of processes up into subsets that overlap

There is consensus within every subset

When a process wishes to enter the CS, it sends a request to every member of its district.

MAEKAWA’S ALGORITHM FOR MUTUAL EXCLUSION CONTD…




When the process receives replies from all the members of the district, it can enter the CS.

When a process receives a request, it responds with a "YES“ if it has not already sent any reply.

When a process exits the CS, it informs the district, which can then reply for other nodes.


Request sets

N = { 1, 2, ..., N }

Ri ∩ Rj ≠ ∅ all i, j ∈ N

A site can send a REPLY message only if it has not been sent a REPLY message after getting a RELEASE message.

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 has not sent a REPLY message to a

site from the time it received the last RELEASE

message. Otherwise it queues up the REQUEST

for latter consideration.

EXECUTING & RELEASING THE CS

Executing the Critical Section

3. Site Si accesses the CS only after receiving REPLY

messages from all the sites in Ri.

Releasing the CS:

4. After the execution of the CS, the site Si sends

RELEASE(i) message to all the sites in Ri.

5. 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 the site updates its state to reflect

that the site has not sent out any REPLY message.

MAEKAWA’S ALGORITHM

With each process i, associate a subset Si. Divide the set of processes into subsets that satisfy the following two conditions:

i ∈ Si

∀i,j : 0≤i,j ≤ n-1 | Si S⋂ j ≠ ∅

Main idea. Each process i is required to receive permission from Si only. Correctness requires that multiple processes will never receive permission from all members of their respective subsets.

0,1,2 1,3,5

2,4,5

S0S1

S2


Example. Let there be seven processes 0, 1, 2, 3, 4, 5, 6

S0 = {0, 1, 2}S1 = {1, 3, 5}S2 = {2, 4, 5}S3 = {0, 3, 4}S4 = {1, 4, 6}S5 = {0, 5, 6}S6 = {2, 3, 6}


Version 1 {Life of process I}

1. Send timestamped request to each process in Si.

2. Request received send ack to process with the

lowest timestamp. Thereafter, "lock" (i.e. commit)

yourself to that process, and keep others waiting.

3. Enter CS if you receive an ack from each member

in Si.

4. To exit CS, send release to every process in Si.

5. Release received unlock yourself. Then send

ack to the next process with the lowest timestamp.

S0= {0, 1, 2}

S1= {1, 3, 5}

S2= {2, 4, 5}

S3= {0, 3, 4}

S4= {1, 4, 6}

S5= {0, 5, 6}

S6= {2, 3, 6}

MAEKAWA’S ALGORITHM-VERSION 1

ME1. At most one process can enter its critical

section at any time.

Let i and j attempt to enter their Critical Sections

Si ∩ Sj ≠ ∅ implies there is a process k ∊ Si S⋂ j

Process k will never send ack to both.

So it will act as the arbitrator and establishes ME1

S0= {0, 1, 2}

S1= {1, 3, 5}

S2= {2, 4, 5}

S3= {0, 3, 4}

S4= {1, 4, 6}

S5= {0, 5, 6}

S6= {2, 3, 6}

MAEKAWA’S ALGORITHM-VERSION 1

ME2. No deadlock. Unfortunately deadlock is

possible! Assume 0, 1, 2 want to enter their

critical sections.

From S0= {0,1,2}, 0,2 send ack to 0, but 1 sends ack to 1;



Now, 0 waits for 1 (to send a release), 1 waits for 2 (to send a

release), , and 2 waits for 0 (to send a release), . So deadlock

is possible!

S0= {0, 1, 2}

S1= {1, 3, 5}

S2= {2, 4, 5}

S3= {0, 3, 4}

S4= {1, 4, 6}

S5= {0, 5, 6}

S6= {2, 3, 6}

TOKEN BASED ALGORITHMS

one token, shared among all sites

site can enter its CS iff it holds token The major difference is the way the token is

searched

use sequence numbers instead of timestamps

used to distinguish requests from same site

kept independently for each site

use sequence number to distinguish between

old and current requests

Token-based ME Algorithms

A unique Token is shared among all sites. A site is allowed to enter the CR if it holds the

Token. Token-based algorithms use a sequence number

instead of timestamps. Correctness proof is trivial. Rather, the issues of freedom from starvation and

freedom from deadlock are more important.

SUZUKI-KASAMI’S BROADCAST ALGORITHM

node holding TOKEN can execute CS repeatedly if no request from others comes

if a node wants TOKEN, it broadcasts a

REQUEST message to all other nodes

node: REQUEST(j, n) node j is requesting n-th CS

invocation n = 1, 2, 3, ... , sequence #

node i receives REQUEST from j update RNi[j] = max ( RNi[j], n )

SUZUKI-KASAMI’S ALGORITHM CONTD…

RNi[j] = largest seq # received so far from node j

TOKEN:

TOKEN(Q, LN ) ( suppose at node i )

Q -- queue of requesting nodes

LN -- array of size N such that

LN[j] = the seq # of the request of node j

granted most recently


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.

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:

3. The site Si executes the CS when it has

received the token.

Release the Critical Section: (after executing

CS)

4. It sets LN[i] element of the token array equal

to Rni[i].

5. 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.


6. If token queue is non empty 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.

SUZUKI KASAMI EXAMPLE

CONSIDER 5 SITES

S1S2

S4

S3

S5

n=1n=2

n=5

n=4

n=3

0

1

0

2

0

3

0

4

0

50

1

0

2

0

3

0

4

0

5

0

1

0

2

0

3

0

4

0

5

0

1

0

2

0

3

0

4

0

5

0

1

0

2

0

3

0

4

0

5

RN1RN2

RN5

RN3

RN4

0

1

0

2

0

3

0

4

0

5

LN

Q { } (empty)

Token at Site S1

SITE S1 WANTS TO ENTER CS

S1 won’t execute Request Part of the algorithm

S1 enters CS as it has token When S1 release CS,it performs following

tasks(i) LN[1] = RN1[1] = 0 i.e. same as before(ii) If during S1’s CS execution, any request

from other site (say S2) have come then that Site’s id will now be entered into the queue if RN1[2] = LN[2]+1

So if site holding (not received from other) the token enters CS then overall state of the system won’t change it remains same.

SITE S2 WANTS TO ENTER CS

S2 does not have token so it sends REQUEST(2,1) message to every other site

Sites S1,S3,S4 and S5 updates their RN as follows

0

1

1

2

0

3

0

4

0

5

It may be possible that S2’s request came at S1 when S1 is under CS executionSo at this point S1 will not pass the token to S2. It will finish its CS and then adds S2 Into Queue because at that point

RN1[2] = 1 which is LN[2]+1Now as the queue is not empty, so S1 pass token to S2 by removing S2 entry from Token queue.

SITE S2 SENDS REQUEST(2,1)

S1S2

S4

S3

S5

n=1n=2

n=5

n=4

0

1

12

0

3

0

4

0

50

1

1

2

0

3

0

4

0

5

0

1

12

0

3

0

4

0

5

0

1

12

0

3

0

4

0

5

0

1

12

0

3

0

4

0

5

RN1RN2

RN3

RN4

0

1

0

2

0

3

0

4

0

5

LN

Q {S2 } [Inserted only when S1 leave CS]

Token at Site S1

REQUEST(2,1)

REQUEST(2,1)

REQUEST(2,1)

REQUEST(2,1)

SITE S1 SENDS TOKEN TO S2

S1S2

S4

S3

S5

n=1n=2

n=5

n=4

0

1

12

0

3

0

4

0

50

1

1

2

0

3

0

4

0

5

0

1

12

0

3

0

4

0

5

0

1

12

0

3

0

4

0

5

0

1

12

0

3

0

4

0

5

RN1RN2

RN3

RN4

LNToken at Site S2

0

1

0

2

0

3

0

4

0

5

Q{}

LN

SITE S2 LEAVES CS

S1S2

S4

S3

S5

n=1n=2

n=5

n=4

0

1

12

0

3

0

4

0

50

1

1

2

0

3

0

4

0

5

0

1

12

0

3

0

4

0

5

0

1

12

0

3

0

4

0

5

0

1

12

0

3

0

4

0

5

RN1RN2

RN3

RN4

LNToken at Site S2

0

1

12

0

3

0

4

0

5

Q{}

LN

NOW SUPPOSE S2 AGAIN WANTS TO ENTER CS S2 can enter CS as token queue is empty i.e.

no other site has requested for CS and token is currently held by S2

When S2 release CS it updates LN[2] as RN2[2] which is same as 1.

SALIENT POINTS A site updates its RN table as soon as it receives

Request message from any other site [At this point a site may hold an ideal token or may be executing CS]

When a site enters CS without sending request message (i.e. when site wants to again enter CS without making request) then its RN entry and LN entry of token remains unchanged

A site can be added in to token queue only by the site who is releasing the CS

A site holding the token can repeatedly enter CS until it does not send token to some other site.

A site gives priority to other sites with outstanding requests for the CS over its pending requests for the CS

RAYMOND’S TREE BASED ALGORITHM

Sites are arranged logically as a tree ( e.g.

minimal spanning tree ) edges are directed

toward the site that holds the token

each site has a variable HOLDER -- indicates

the location of TOKEN relative to the site

( node ) itself

RAYMOND’S TREE BASED ALGORITHM CONTD…


HOLDER(A) = D

HOLDER(B) = A

HOLDER(C) = A

HOLDER(D) = E

HOLDER(E) = self

HOLDER(F) = D




When a nontoken-node (e.g. A ) wants to

enter CS, it sends REQUEST to HOLDER(A)

( i.e. D )

D sends REQUEST to HOLDER(D), i.e. E

when E no longer needs TOKEN, it sends

TOKEN to one of its neighbours who has

requested TOKEN


Si requests entry to CS

if Si does not hold the token and Qi is empty then send request to holderi

add Si to Qi

Sj receives request from Si

if Sj is holding token send token to Si

set holderj to Si

if Sj is not holding token place request in Qj

if Sj does not have a pending request then send request to holderj


Si receives token

delete top entry Sj from Qi

if k = i enter own critical section if k not i then

{ send token to Sj; set holderi to Sj }

Si leaves a CS

if Qi is nonempty then{ delete top entry Sj from Qi; send token to Sj; set holderi to Sj }

if Qi is (still) nonempty then send request to holderi




Initially, P0 holds the token. Also, P0 is the current root.

P3 wants the token to get into its critical section.So, P3 adds itself to its own FIFO queue and sends a request message to its parent P2.

P2 receives the request from P3. It adds P3 to its FIFO queue and passes the request message to its parent P1.

P1 receives the request from P2. It adds P3 to its FIFO queue and passes the request message to its parent P0

At this point, P2 also wants the token. Since its FIFO queue is not empty, it adds itself to its own FIFO queue.

P0 receives the request message from P3 though P1. It surrenders the token and passes it on to P1.It also changes the direction of the arrow between them,making P1 the root, temporarily.

P1 removes the top element of its FIFO queue to see which node requested the token.Since the token needs to go to P3, P1 surrenders the token and passes it on to P2.It also changes the direction of the arrow between them, making P2 the root, temporarily.

P2 removes the top element of its FIFO queue to see which node requested the token.Since the token needs to go to P3, P2 surrenders the token and passes it on to P3.It also changes the direction of the arrow between them, making P3 the root.

Now, P3 holds the token and can execute its critical section.It is able to clear the top (and only) element of its FIFO queue.Note that P3 is the current root.

In the meantime, P2 checks the top element of its FIFO queue and realizes that it also needs to request the token.So, P2 sends a request message to its current parent, P3, who appends the request to its FIFO queue.

As soon as P3 completes its critical section, it checks the top element of its FIFO queue to see if it is needed elsewhere.In this case, P2 has requested it, so P3 sends it back to P2.It also changes the direction of the arrow between them, making P2 the new root.

P2 holds the token and is able to complete its critical section.Then it checks its FIFO queue, which is empty.

So it waits until some other node requests the token.

Algorithm Response time

SD # of messages

(LL)

# of messages

(HL)

Lamport 2T + E T 3(n – 1) 3(n –1)

Ricart-Agrawala

2T + E T 2(n – 1) 2(n – 1)

Maekawa 2T + E 2T 3(sqrt(n) + 1)

5(sqrt(n) + 1)

Suzuki-Kasami

2T + E T n n

Sinhal 2T + E T n/2 n

Raymond T(log n) + E Tlog n/2 log n 4

LL: Light Load, HL: Heavy Load

Comparison of Distributed ME Algorithms

Documents

D ISTRIBUTED S YSTEM M UTUAL E XCLUSION UNIT-3. D ISTRIBUTED M UTUAL E XCLUSION Concurrent access to a shared resource (critical region) by several