ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.
-
Upload
geraldine-carr -
Category
Documents
-
view
212 -
download
0
Transcript of ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.
![Page 1: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/1.jpg)
ITEC452Distributed Computing
Lecture 6Mutual Exclusion
Hwajung Lee
![Page 2: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/2.jpg)
Mutual Exclusion
CS
CS
CS
CSp0
p1
p2
p3
![Page 3: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/3.jpg)
Why mutual exclusion?
Some applications are:
1. Resource sharing
2. Avoiding concurrent update on shared data
3. Controlling the grain of atomicity
4. Medium Access Control in Ethernet
5. Collision avoidance in wireless broadcasts
![Page 4: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/4.jpg)
Specifications
ME1. At most one process in the CS. (Safety property)ME2. No deadlock. (Safety property)ME3. Every process trying to enter its CS must eventually succeed.
This is called progress. (Liveness property)
Progress is quantified by the criterion of bounded waiting. It measuresa form of fairness by answering the question: Between two consecutive CS trips by one process, how many times other processes can enter the CS?
There are many solutions, both on the shared memory model and the message-passing model
![Page 5: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/5.jpg)
Message passing solution:Centralized decision
making
clients
Clientdo true
send request;reply received enter CS;send release;<other work>
od
Serverdo request received and not busy send reply; busy:= true request received and busy enqueue sender release received and queue is empty busy:= false release received and queue not empty send reply
to the head of the queueod
busy: boolean
server
queue
req replyrelease
![Page 6: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/6.jpg)
Comments
- Centralized solution is simple.
- But the server is a single point of failure. This is BAD.
- ME1-ME3 is satisfied, but FIFO fairness is not guaranteed. Why?
Can we do better? Yes!
![Page 7: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/7.jpg)
Decentralized solution 1
{Lamport’s algorithm}1. Broadcast a timestamped request to all.
2. Request received enqueue it in local Q. Not in CS send ack, else postpone sending ack until exit from CS.
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.
0 1
2 3
Q0 Q1
Q2 Q3
Completely connected topology
![Page 8: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/8.jpg)
Analysis of Lamport’s algorithm
Can you show that it satisfies all the properties
(i.e. ME1, ME2, ME3) of a correct solution?
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.
Proof by contradiction
Suppose not, and both j,k enter their CS. This implies
j in CS Qj.ts.j < Qk.ts.k k in CS Qk.ts.k < Qj.ts.j
Impossible.
0 1
2 3
Q0 Q1
Q2 Q3
![Page 9: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/9.jpg)
Analysis of Lamport’s algorithm
Proof of ME2. (No deadlock)
The waiting chain is acyclic.
i waits for j
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
0 1
2 3
Q0 Q1
Q2 Q3
![Page 10: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/10.jpg)
Analysis of Lamport’s algorithm
Proof of FIFO fairness.
Proof by contradiction
timestamp (j) < timestamp (k)
j enters its CS before k does so
Suppose not. So, k enters its CS before j, which means k did not receive j’s request but received the ack from j for its own req.
This is impossible if the channels are FIFO
Message complexity of each process in one round trip to CS = 3(N-1)
(N-1 requests + N-1 ack + N-1 release)
k j
Req
(20)
ack
Req (30)
![Page 11: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/11.jpg)
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 higher 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)
![Page 12: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/12.jpg)
Ricart & Agrawala’s algorithm
{Ricart & Agrawala’s algorithm}
ME1. Prove that at most one process can be in CS.
Proof (by contradiction)
Suppose not. Two processes k and j can enter the CS at the same time, only if both k and j received n-1 acks. However, both k and j cannot send ack to each other. Thus, impossible.
ME2. Prove that deadlock is not possible.
Proof
The waiting chain is acyclic.
k waits for j
k is behind j in all queues (or j is in its CS)
j does not wait for k
k j
Req(j)
Ack(j)
TS(j) < TS(k)
Req(k)
![Page 13: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/13.jpg)
Ricart & Agrawala’s algorithm
{Ricart & Agrawala’s algorithm}
ME3. Prove that FIFO fairness holds even if channels
are not FIFOProof. If TS(j) < TS(k), then process j is ranked higher
than (i.e., ahead of) k in the wait-for chain. Therefore, process j will enter the CS before process k.
Message complexity = 2(N-1)
(N-1 requests + N-1 acks - no release message)
k j
Req(j)
Ack(j)
TS(j) < TS(k)
Req(k)
![Page 14: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/14.jpg)
Unbounded timestamps
Timestamps grow in an unbounded manner.
This makes real implementation impossible.
Can we somehow bounded timestamps?
Think about it.
![Page 15: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/15.jpg)
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
![Page 16: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/16.jpg)
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 : i,j n-1 :: Si Sj ≠
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
![Page 17: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/17.jpg)
Maekawa’s algorithm
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}
![Page 18: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/18.jpg)
Maekawa’s algorithm
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}
![Page 19: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/19.jpg)
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 ≠ there is a process k Si Sj
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}
![Page 20: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/20.jpg)
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;
From S1= {1,3,5}, 1,3 send ack to 1, but 5 sends ack to
2;
From S2= {2,4,5}, 4,5 send ack to 2, but 2 sends ack to
0;
Now, 0 waits for 1, 1 waits for 2, and 2 waitsfor 0. 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}
![Page 21: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/21.jpg)
Maekawa’s algorithm-Version 2
Avoiding deadlockIf processes receive messages in increasing
order of timestamp, then deadlock “could be” avoided. But this is too strong an assumption.
Version 2 uses three additional messages:
- failed
- inquire
- relinquish
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}
![Page 22: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/22.jpg)
Maekawa’s algorithm-Version 2
New features in version 2
- Send ack and set lock as usual.- If lock is set and a request with larger
timestamp arrives, send failed (you have no chance). If the incoming request has a lower timestamp, then send inquire (are you in CS?) to the locked process.
- Receive inquire and at least one failed message send relinquish. The recipient resets the lock.
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}
![Page 23: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/23.jpg)
Maekawa’s algorithm-Version 2
0
1
2
34
5
6
12
18
0
1
2
34
5
6
12
18ack
req
req
inquire
25req failed
![Page 24: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/24.jpg)
Comments
- Let K = |Si|. Let each process be a member of D subsets. When N = 7, K = D = 3. When K=D, N = K(K-1)+1. So K is of the order √N
- The message complexity of Version 1 is 3√N. Maekawa’s analysis of Version 2 reveals a complexity of 7√N
Sanders identified a bug in version 2 …
![Page 25: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/25.jpg)
Token-passing Algorithms
Suzuki-Kasami algorithmThe 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 CSI want to enter CS
![Page 26: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/26.jpg)
Suzuki-Kasami Algorithm
Process i broadcasts (i, num)
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 from for process j.- a queue Q of waiting processes req: array[0..n-1] of integer
last: array [0..n-1] of integer
Sequence number of the request
req
req
req
req
reqlast
queue Q
![Page 27: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/27.jpg)
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 if1+ last[k] = req[k] (This guarantees the freshness of the request)
--Sends the token to the head of Q, along withthe array last and the tail of Q
In fact, token (Q, last)
Req: array[0..n-1] of integer
Last: Array [0..n-1] of integer
![Page 28: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/28.jpg)
Suzuki-Kasami’s algorithm
{Program of process j}Initially, i: req[i] = last[i] = 0* Entry protocol *
req[j] := req[j] + 1Send (j, req[j]) to allWait until token (Q, last) arrivesCritical Section
* Exit protocol *last[j] := req[j]k ≠ j: k Q req[k] = last[k] + 1 append k to Q;if Q is not empty send (tail-of-Q, last) to head-of-Q fi
* Upon receiving a request (k, num) *req[k] := max(req[k], num)
![Page 29: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/29.jpg)
Example
0
2
1
3
4
req=[1,0,0,0,0]last=[0,0,0,0,0]
req=[1,0,0,0,0]
req=[1,0,0,0,0]
req=[1,0,0,0,0]
req=[1,0,0,0,0]
initial state
![Page 30: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/30.jpg)
Example
0
2
1
3
4
req=[1,1,1,0,0]last=[0,0,0,0,0]
req=[1,1,1,0,0]
req=[1,1,1,0,0]
req=[1,1,1,0,0]
req=[1,1,1,0,0]
1 & 2 send requests
![Page 31: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/31.jpg)
Example
0
2
1
3
4
req=[1,1,1,0,0]last=[1,0,0,0,0]Q=(1,2)
req=[1,1,1,0,0]
req=[1,1,1,0,0]
req=[1,1,1,0,0]
req=[1,1,1,0,0]
0 prepares to exit CS
![Page 32: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/32.jpg)
Example
0
2
1
3
4
req=[1,1,1,0,0]
req=[1,1,1,0,0]last=[1,0,0,0,0]Q=(2)
req=[1,1,1,0,0]
req=[1,1,1,0,0]
req=[1,1,1,0,0]
0 passes token (Q and last) to 1
![Page 33: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/33.jpg)
Example
0
2
1
3
4
req=[2,1,1,1,0]
req=[2,1,1,1,0]last=[1,0,0,0,0]Q=(2,0,3)
req=[2,1,1,1,0]
req=[2,1,1,1,0]
req=[2,1,1,1,0]
0 and 3 send requests
![Page 34: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/34.jpg)
Example
0
2
1
3
4
req=[2,1,1,1,0]
req=[2,1,1,1,0]
req=[2,1,1,1,0]last=[1,1,0,0,0]Q=(0,3)
req=[2,1,1,1,0]
req=[2,1,1,1,0]
1 sends token to 2
![Page 35: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/35.jpg)
Raymond’s tree-based algorithm
123 4 5
6 71,4
4,7
1
1
4
1,4,7 want to enter their CS
![Page 36: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/36.jpg)
Raymond’s Algorithm
123 4 5
6 71,4 4,7
1
4
2 sends the token to 6
![Page 37: ITEC452 Distributed Computing Lecture 6 Mutual Exclusion Hwajung Lee.](https://reader035.fdocuments.in/reader035/viewer/2022070414/5697c0051a28abf838cc5012/html5/thumbnails/37.jpg)
Raymond’s Algorithm
123 4 5
6 7
4
4,7
4
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)
6 forwards the token to 1
4