UNIT7 MUTUAL EXCLUSION.pdf

8/18/2019 UNIT7 MUTUAL EXCLUSION.pdf

1/40

Mutual Exclusion & Election

Brian Nielsen

[email protected]


2/40

Failure model• Assumptions:

– reliable channels (eventual delivery)

– Independent processes

– crash failures (fail-stop)

Crashedrouter

Network Partitioning


3/40

Failure Detection• Failure detector: a service that may be queried about

the failure state of other processes – Unreliable detector: answers Unsuspected or Suspected

– Reliable detector answers Unsuspected or Failed

• Failure Detection Algorithm – Probing: pi sends “Are you Alive?” to p j

– Heartbeat messages:• Every process pi broadcasts “I am alive” message every T sec.

• Estimated Network Delay: D

• P j declares pi suspected if no heartbeat within T+D

• Too small D ⇒ alive process reported dead

• Too large D ⇒ Crashed process reported alive

• Synchronous system

– All messages arrive within D units of time.

– Allows reliable failure detectors


4/40

Distributed mutual exclusion• A number of processes want to access some shared resource

• Prevent interference, maintain consistency; critical section.

Resource

P1 P2 PiPN… …

Application-level protocol:

enter() // block till free

resourceAccess() // critical section

exit() // free resource

General requirements for mutual exclusion

ME1: safety: at most one process may execute in the critical section at a time

ME2: liveness: requests eventually succeed (no deadlock, no starvation)

ME3: fairness (ordering): if request A happens-before request B then grant A before gran

Problems: fault tolerance, performance


5/40

Performance Measures• Bandwith: number of messages required

for entry and exit

• Client delay (entry and exit)

• Throughput (Synchronization delay)

P1 Request P1 Grant P1 Exit R Free

P2 Request

P2 Grant

Time


6/40

Mutual Exclusion: A

Centralized Algorithm• A process is elected as coordinator

• Whenever a process wants to enter a criticalregion, it sends a request message to the

coordinator stating which critical region it wants

to enter and asking for permission.• Permission is granted only if a different process

is not already in the critical region.

• Requests are granted in the order in which they

are received (fair).


7/40

Mutual Exclusion: A

Centralized Algorithm

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 thecoordinator, which then replies to 2


8/40

Mutual Exclusion: A

Centralized Algorithm• Shortcomings

– The coordinator is a single point of failure, soif it crashes, the entire system may go down.

• Wait; why not just elect another coordinator?

• You can. The only concern is figuring out who has

access to the critical section.

• How do you tell the difference between a dead

coordinator and “permission denied”? – In a large system a single coordinator may

become a performance bottleneck.


9/40

Mutual Exclusion: A

Centralized Algorithm• Bandwidth

– 3 messages to enter and leave a criticalregion: A request, a grant to enter and a

release to exit

• Client Delay:

– Entry: 2 messages: request+grant

– Exit: 0 (asynchrounous sending of release)

• Synchronization Delay: release + grant


10/40

A Token Ring Algorithm

a) An unordered group of processes on a network.

b) A logical ring constructed in software.

c) Token holder may enter CS


11/40

A Token Ring Algorithm• 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.

• When a process acquires the token from its

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

• Token is passed to the next process in the ring.


12/40

A Token Ring Algorithm• Shortcomings

– If the token is lost, it must be regenerated. – Very difficult to determine if a token is lost since a

process may be in a critical section for a long time.

– If there is a crash, recovery is easier than in othercases.

• If we require a process receiving the token to acknowledge

receipt, a dead process will be detected when its neighbor

tries to give it the token and fails.• The token is passed to the successor of the dead process.

• This requires that each process knows the ring configuration.


13/40

A Token Ring Algorithm• Bandwidth

– Variable number of messages needed – If every process constantly wants to enter a critical region, then

each token pass will result in one entry and one exit.

– The token may circulate for hours without anyone being

interested in it. In this case, the number of messages per entryinto a critical region is unbounded.

– We note that there is delay in from the moment a process needs

to enter a critical region until its actual entry.

• If the token just left, it needs to wait until the token has gone throughthe n-1 nodes.

• If the token just arrived, there is no wait.


14/40

Token Ring• Client Delay

– Entry: Wait: 0…N hops (N/2 in average)

– Exit: send 1 msg (asynchronously)

• Synchronization Delay – 0…N hops (N/2 in average)


15/40

Ricart and Agrawala’s

Algorithm [`81]• Fully Distributed

• Optimized version of Lamports ’78algorithm

• Send “request” to N–1 other processes.• Execute CS when “reply OK” permission is

received from all other processes.

• Pi maintains Lamport Clock

• Break ties with timestamps (Lamport

timestamp).


16/40

Ricart and Agrawala

• The general idea: – ask everybody

– wait for permission fromeverybody

Pi

Pi

Pi

Pi

resource

?

The problem: – several simultaneous requests (e.g., Pi and P j)

– all members have to agree (everybody: “first Pithen P j”)


17/40

On initializationstate := RELEASED;

To enter the sectionstate := WANTED;

T := request’s timestamp; request processing deferred hereMulticast request to all other processes;Wait until (number of replies received = ( N-1) );state := HELD;

On receipt of a request at p j (i ≠ j)if (state = HELD or (state = WANTED and (T , p j) < (T i, pi)))then

queue request from pi without replying;else

reply OK immediately to pi;end if;

To exit the critical sectionstate := RELEASED;reply OK to all queued requests;

Ricart – Agrawal’s Algorithm


18/40

Ricart – Agrawala EX.

p3

34

OK

41

41

34

OK

Decision base:

Lamport timestamp

41X

OK

34

X

P1 and P2 requests access concurrently at time 41 and 34

X=bug in book illustration

p1

p2


19/40

Performance• Gaining entry: 2(n-1) messages per

request without HW-multicast – N-1 to multicast request

– N-1 replies

• Client Entry Delay: 1 round-trip time

(multicasting is counted as 1 step)

• Client Exit Delay: 1 message

• Synchronization delay is one message


20/40

Maekawa’s Algorithm [1981]• Idea: Get permission from only a subset of

processes. – quorum:• ”The minimal number of officers and members of a

committee or organization, usually a majority, who must

be present for valid transaction of business.”


21/40

Voting

p5

V2

V3

V1

p1 p2 p3

p6

p4

•To enter its CS, a process gets permission from all members of its group

•A process may grant permission to only one process at a time

(between each request / release pair

•Complexity depends on group size

•Want to minimize group size


22/40

Voting-SetsVoting-set Vi for Pi

1. ∀i, j: Vi ∩ V ≠∅

• Safety: at least one common member of any two voting-sets

2. Vi contains process pi• Saves a message

3. |V1| = |V2| = … = |VN| = K• Fairness: every process has a voting set of the same size

4. Each process is in M of the voting sets Vi’s

• Each processor has the same responsibility

Minimal K satisfying 1..4 is c√N.


23/40

Heuristic for Constructing

Quorums

• Example of Quorums for N=36, K=6

• √N by √N Matrix:

V14

|Vi| = 2√N -1


24/40

Maekawa’s algorithm – part 1On initialization

state := RELEASED;

voted := FALSE;

For pi to enter the critical section

state := WANTED;

Multicast request to all processes in V i – { pi};

Wait until (number of replies received = (K – 1));

state := HELD;On receipt of a request from pi at p j (i ≠ j)

if (state = HELD or voted = TRUE)

then

queue request from pi without replying;else

send reply to pi;

voted := TRUE;

end if


25/40

Maekawa’s algorithm – part 2 For pi to exit the critical section

state := RELEASED;Multicast release to all processes in V i – { pi};

On receipt of a release from pi at p j (i ≠ j)

if (queue of requests is non-empty)

then

remove head of queue – from pk , say;

send reply to pk ;

voted := TRUE;

else

voted := FALSE;end if


26/40

Deadlock Example

Q2Q2

Q2

Q4

Q4Q4

Q6

Q6Q6

L

L

L

Concurrent request⇒

common processes votes to left most quorum⇒

Circular wait possible ⇒ deadlock possible


27/40

Performance• Bandwidth: 3√N

– 2√N messages per entry

– √N messages per release

• Client Entry Delay: 1 round-trip time(multicasting is counted as 1 step)

• Client Exit Delay: 1 message

(multicasting is counted as 1 step)• Synchronization delay: 1 roundtrip


28/40

Comparison

A comparison of mutual exclusion algorithms.

Notice: the system may contain a remarkable amount of

sharable resources!

Lost token,

process crash0..n-1 (Avg: n/2)1 … ∞Token ring

Crash of process

in voting set23√N

Maekava

voting

Crash of anyprocess

12 ( n – 1 )Ricart & Agrawali

Coordinator crash23Centralized

ProblemsSynchronization

Delay (seq. msgs)

Messages per

entry/exit Algorithm


29/40

Summary• All distributed algorithms suffer badly in

event of crashes.• Special measures and additional

complexity must be introduced to avoid

having a crash bring down the entire

system.


30/40

Election Algorithms• Need:

– computation: a group of concurrent processes

– algorithms based on the activity of a special role(coordinator, initiator)

– election of a coordinator: initially or after somespecial event (e.g., the previous coordinator hasdisappeared)

• Premises: – each member of the group

• knows the identities of all other members

• does not know who is up and who is down – all electors use the same algorithm

– election rule: the member with the highest process id


31/40

Election Requirements• E1: (safety) A participant process pi has

either electedi=⊥, or electedi=p, where p isthe non-crashed process having thelargest process identifier

• E2: (liveness) All processes pi participateand will at some point in time set theirelectedi variable to a value different from ⊥

or crash• ⊥ = undefined


32/40

A ring-based election 1

17

24

1

2815

9

4

3

17

C=28

17,24

17,24,1

17,24,1,28

17,24,1,28,15

17,24,1,28,15,9

17,24,1,28,15,9,4

17,24,1,28,15,9,4,3


33/40

Chang-Roberts• Improvement Idea:

– When a node receives a token with smaller idthan itself, why should it keep forwarding it?

– It is a waste, we know that that id will never

win!

– Lets drop tokens with smaller ids than

ourselves!

– Mark nodes that has already participated in an

ongoing election to kill concurrent elections


34/40

Chang-Roberts

17

24

1

2815

9

4

3

17

C=28

24

24

28

28

28

28

2828

28

28


35/40

Performance• Bandwidth: 3N-1

– N-1 in worst case to reach process withhighest ID +

– One round of N messages before node with

highest ID can announce it is a winner +

– One round of N messages to inform other

nodes about coordinator

• Turnaround: an election takes sequential 3

rounds


36/40

Bully Algorithm• Bully

– A person who is habitually cruel, especially to smaller

or weaker people• Processes may fail during election

• Uses timeout to detect failure (⇒assumes

synchronous system)• Each process knows processes with higher ID’s

• 3 message types

– A process sends Election to all processes with largerIDs to start an election

– Answer (OK): to election message tells receiver thatsender is alive and that receiver must shut-up

– Coordinator: inform about new coordinator

Th B ll Al i h (2)


37/40

The Bully Algorithm (2)

Coordinator id 7 found dead( a ) Process 4 holds an election

( b ) Process 5 and 6 respond, telling 4 to stop

( c ) Now 5 and 6 each hold an election

Th B ll Al ith (3)


38/40

The Bully Algorithm (3)

( d) Process 6 tells 5 to stop

( e) Process 6 wins and tells everyone


39/40

The bully algorithm

p1 p2

p3

p4

p1

p2

p3

p4

C

coordinator

Stage 4

C

election

election

Stage 2

p1

p2

p3

p4

C

election

answer

answer

electionStage 1

timeout

Stage 3

Eventually.....

p1

p2

p3

p4

election

answer

• Coordinator p4 fail

• P1 decides to hold an election

• P2and p

3tells P

1to shut up and

hold their own (concurrent)

elections

• p3 tells P2 to shut up

• p3 times out waiting from answer

from P3 and declares itself thecoordinator

• Alas, P3 fails

• P1 times out waiting for

coordinator and decides to holdan election

• P2 starts an election and

realizes that it is largest living

process and declares itself the

coordinator p2,


40/40

END

UNIT7 MUTUAL EXCLUSION.pdf

Documents

Transcript of UNIT7 MUTUAL EXCLUSION.pdf