Permissionbased Ricart amp Agrawala Quorumbased Maekawa Tokenbased Raymond Resource Allocation 1 Distributed Mutual Exclusion Mutual Exclusion a resource granted to a process must be released before it can be granted to another process ID: 633994
Download Presentation The PPT/PDF document "Resource Allocation Distributed mutual e..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Resource Allocation
Distributed mutual exclusionPermission-based (Ricart & Agrawala)Quorum-based (Maekawa)Token-based (Raymond)
Resource Allocation
1Slide2
Distributed Mutual Exclusion
Mutual Exclusion:a resource granted to a process must be released before it can be granted to another processConditions for Distributed Mutual Exclusion:Requests for a resource should be granted in the order in which they were madeEvery granted resource will eventually be released, to ensure every request will eventually be granted
Resource Allocation > Distributed Mutual Exclusion
2Slide3
Deadlock and Starvation
Deadlock:Occurs when no process in the system is in its critical section and no requesting process can ever proceed to its own critical sectionStarvation:Occurs when one process must wait indefinitely to enter its critical section even though other nodes are entering and exiting their own critical sections
Resource Allocation > Distributed Mutual Exclusion
3Slide4
Quorum-Based Algorithms
Algorithms that ensure mutual exclusion by obtaining permission from every member of a minimum set of processes (i.e., a quorum)Whenever a process requests a resource, it must request permission from every process in its quorumTo avoid violation of mutual exclusion, quorums must adhere to the non-null intersection propertyResource Allocation > Distributed Mutual Exclusion > Quorum-Based
4Slide5
Non-Null Intersection Property
For any combination of i and j, 1 ≤ i, j ≤ N, Si
∩ Sj ≠ Ø
For any pair of processes, their quorums must share at least one member
Two creation methods on order of
√
N
P
rojective planes
Square grid
Resource Allocation > Distributed Mutual Exclusion > Quorum-Based
5Slide6
Projective Plane Quorums
Based on the mathematical concept of finite projective planes, in which parallel lines eventually intersect at points near infinitySize of each quorum is K, where N ≤ K(K – 1) + 1K = 2 for 1 ≤ N ≤ 3K = 3 for 4 ≤ N ≤ 7K = 4 for 8 ≤ N ≤ 13
K = 5 for 14 ≤ N ≤ 21
Resource Allocation > Distributed Mutual Exclusion > Quorum-Based
6Slide7
Projective Plane Example
N = 6, hence K = 3Resource Allocation > Distributed Mutual Exclusion > Quorum-Based
7
1
2
3
4
5
6
1
2
3
4
5
6Slide8
Projective Plane Example
N = 6, hence K = 3First, every process should be a member of its own quorumResource Allocation > Distributed Mutual Exclusion > Quorum-Based
8
1
2
3
4
5
6
1
2
3
4
5
6Slide9
Projective Plane Example
N = 6, hence K = 3First, every process should be a member of its own quorumResource Allocation > Distributed Mutual Exclusion > Quorum-Based
9
1
2
3
4
5
6
1
X
2
X
3
X
4
X
5
X
6
XSlide10
Projective Plane Example
N = 6, hence K = 3Select enough processes to complete K for one process (node #1)Resource Allocation > Distributed Mutual Exclusion > Quorum-Based
10
1
2
3
4
5
6
1
X
2
X
3
X
4
X
5
X
6
XSlide11
Projective Plane Example
N = 6, hence K = 3Select enough processes to complete K for one process (node #1)Resource Allocation > Distributed Mutual Exclusion > Quorum-Based
11
1
2
3
4
5
6
1
X
X
X
2
X
3
X
4
X
5
X
6
XSlide12
Projective Plane Example
N = 6, hence K = 3Ensure every other process shares at least one process with the latest quorum (node #1)Resource Allocation > Distributed Mutual Exclusion > Quorum-Based
12
1
2
3
4
5
6
1
X
X
X
2
X
3
X
4
X
5
X
6
XSlide13
Projective Plane Example
N = 6, hence K = 3Ensure every other process shares at least one process with the latest quorum (node #1)Resource Allocation > Distributed Mutual Exclusion > Quorum-Based
13
1
2
3
4
5
6
1
X
X
X
2
X
3
X
4
X
5
X
6
X
OR
OR
ORSlide14
Projective Plane Example
N = 6, hence K = 3Select enough processes to complete K for one process (node #6) not in the latest quorum
Resource Allocation > Distributed Mutual Exclusion > Quorum-Based
14
1
2
3
4
5
6
1
X
X
X
2
X
3
X
4
X
5
X
6
X
OR
OR
ORSlide15
Projective Plane Example
N = 6, hence K = 3Select enough processes to complete K for one process (node #6) not in the latest quorum
Resource Allocation > Distributed Mutual Exclusion > Quorum-Based
15
1
2
3
4
5
6
1
X
X
X
2
X
3
X
4
X
5
X
6
X
X
X
OR
ORSlide16
Projective Plane Example
N = 6, hence K = 3Ensure every other process shares at least one process with the latest quorum (node #6)Resource Allocation > Distributed Mutual Exclusion > Quorum-Based
16
1
2
3
4
5
6
1
X
X
X
2
X
3
X
4
X
5
X
6
X
X
X
OR
ORSlide17
Projective Plane Example
N = 6, hence K = 3Ensure every other process shares at least one process with the latest quorum (node #6)Resource Allocation > Distributed Mutual Exclusion > Quorum-Based
17
1
2
3
4
5
6
1
X
X
X
2
X
3
X
4
X
5
X
6
X
X
X
OR
OR
OR
ORSlide18
Projective Plane Example
N = 6, hence K = 3Select enough processes to complete K for one process (node #4) not in the latest quorumResource Allocation > Distributed Mutual Exclusion > Quorum-Based
18
1
2
3
4
5
6
1
X
X
X
2
X
3
X
4
X
5
X
6
X
X
X
OR
OR
OR
ORSlide19
Projective Plane Example
N = 6, hence K = 3Select enough processes to complete K for one process (node #4) not in the latest quorumResource Allocation > Distributed Mutual Exclusion > Quorum-Based
19
1
2
3
4
5
6
1
X
X
X
2
X
3
X
4
X
X
X
5
X
6
X
X
X
OR
ORSlide20
Projective Plane Example
N = 6, hence K = 3Ensure every other process shares at least one process with the latest quorum (node #4)Resource Allocation > Distributed Mutual Exclusion > Quorum-Based
20
1
2
3
4
5
6
1
X
X
X
2
X
3
X
4
X
X
X
5
X
6
X
X
X
OR
ORSlide21
Projective Plane Example
N = 6, hence K = 3Ensure every other process shares at least one process with the latest quorum (node #4)Resource Allocation > Distributed Mutual Exclusion > Quorum-Based
21
1
2
3
4
5
6
1
X
X
X
2
X
3
X
4
X
X
X
5
X
6
X
X
X
OR
OR
OR
OR
ORSlide22
Projective Plane Example
N = 6, hence K = 3Select enough processes to complete K for one process (node #2) not in the latest quorumResource Allocation > Distributed Mutual Exclusion > Quorum-Based
22
1
2
3
4
5
6
1
X
X
X
2
X
3
X
4
X
X
X
5
X
6
X
X
X
OR
OR
OR
OR
ORSlide23
Projective Plane Example
N = 6, hence K = 3Select enough processes to complete K for one process (node #2) not in the latest quorumResource Allocation > Distributed Mutual Exclusion > Quorum-Based
23
1
2
3
4
5
6
1
X
X
X
2
X
X
X
3
X
4
X
X
X
5
X
6
X
X
X
OR
OR
ORSlide24
Projective Plane Example
N = 6, hence K = 3Ensure every other process shares at least one process with the latest quorum (node #2)Resource Allocation > Distributed Mutual Exclusion > Quorum-Based
24
1
2
3
4
5
6
1
X
X
X
2
X
X
X
3
X
4
X
X
X
5
X
6
X
X
X
OR
OR
ORSlide25
Projective Plane Example
N = 6, hence K = 3Ensure every other process shares at least one process with the latest quorum (node #2)Resource Allocation > Distributed Mutual Exclusion > Quorum-Based
25
1
2
3
4
5
6
1
X
X
X
2
X
X
X
3
X
X
4
X
X
X
5
X
6
X
X
X
OR
OR
ORSlide26
Projective Plane Example
N = 6, hence K = 3Follow through other requirements to ensure there’s no conflictsResource Allocation > Distributed Mutual Exclusion > Quorum-Based
26
1
2
3
4
5
6
1
X
X
X
2
X
X
X
3
X
X
4
X
X
X
5
X
6
X
X
X
OR
OR
ORSlide27
Projective Plane Example
N = 6, hence K = 3Follow through other requirements to ensure there’s no conflictsResource Allocation > Distributed Mutual Exclusion > Quorum-Based
27
1
2
3
4
5
6
1
X
X
X
2
X
X
X
3
X
X
4
X
X
X
5
X
X
6
X
X
X
ORSlide28
Projective Plane Example
N = 6, hence K = 3Follow through other requirements to ensure there’s no conflictsResource Allocation > Distributed Mutual Exclusion > Quorum-Based
28
1
2
3
4
5
6
1
X
X
X
2
X
X
X
3
X
X
X
4
X
X
X
5
X
X
X
6
X
X
XSlide29
Projective Plane Example
N = 6, hence K = 3S1 = {1, 2, 3}S2 = {2, 5, 6}S3 = {2, 3, 4}
S4 = {1, 4, 6}
S
5
=
{1, 4, 5}
S
6
=
{3, 5, 6}
Resource Allocation > Distributed Mutual Exclusion > Quorum-Based
29
1
2
3
4
5
6
1
X
X
X
2
X
X
X
3
X
X
X
4
X
X
X
5
X
X
X
6
X
X
XSlide30
Square Grid Quorums
Based on a K x K grid, where N ≤ K2K = 2 for 1 ≤ N ≤ 4K = 3 for 5 ≤ N ≤ 9K = 4 for 10 ≤ N ≤ 16K = 5 for
17 ≤ N ≤ 25Resource Allocation > Distributed Mutual Exclusion > Quorum-Based
30Slide31
Square Grid Example
N = 6, hence K = 3Quorum members come from same row and same column in gridS1 = {1, 2, 3, 4}
Resource Allocation > Distributed Mutual Exclusion > Quorum-Based
31
1
2
3
4
5
6Slide32
Square Grid Example
N = 6, hence K = 3S1 = {1, 2, 3, 4}S2 = {1, 2, 3, 5}S3 = {1, 2, 3, 6}S
4 = {1, 4, 5, 6}S5
= {2, 4, 5, 6}
S
6
= {3, 4, 5, 6}
Resource Allocation > Distributed Mutual Exclusion > Quorum-Based
32
1
2
3
4
5
6Slide33
Maekawa
AlgorithmAssumptionsChannels causally order messages (FIFO)Consider a RELEASE surpassed by a REQUESTEvery message is eventually delivered (i.e., lossless network)Node failure can be detected and failed nodes removed
A REQUEST(Ti,
i
) precedes another REQUEST(
T
j
,
j
),
if (
T
i
<
T
j
), or (
T
i
=
T
j
and
i
<
j
)
Resource Allocation > Distributed Mutual Exclusion > Quorum-Based >
Maekawa
33Slide34
Maekawa
AlgorithmRule 1When process i invokes mutual exclusion, it sends a REQUEST(TS, i) message to all processes in its quorum S
i, where Ts
is greater than any timestamp received by process
i
.
Resource Allocation > Distributed Mutual Exclusion > Quorum-Based >
Maekawa
34Slide35
Maekawa
AlgorithmRule 2Upon receiving a REQUEST(TS, i) message, the receiving process j will queue the request and:Send a LOCKED message to process
i, if j is not currently locked by another request
Send a FAILED message to process
i
, if any other queued requests precede the new request
Send an INQUIRY message to process
k
, if the new request precedes the locked request from
k
Resource Allocation > Distributed Mutual Exclusion > Quorum-Based >
Maekawa
35Slide36
Maekawa
AlgorithmRule 3Upon receiving an INQUIRE message, the receiving process i will return a RELINQUISH message if it has received or will ever receive a FAILED message.Resource Allocation > Distributed Mutual Exclusion > Quorum-Based >
Maekawa
36Slide37
Maekawa
AlgorithmRule 4Upon receiving a RELINQUISH message, the receiving process j will lock itself for the most preceding request in its queue and will send a LOCKED message to the sender of that request.Resource Allocation > Distributed Mutual Exclusion > Quorum-Based >
Maekawa
37Slide38
Maekawa
AlgorithmRule 5Upon receiving a LOCKED message from every member of Si, process i enters its critical section.
Resource Allocation > Distributed Mutual Exclusion > Quorum-Based > Maekawa
38Slide39
Maekawa
AlgorithmRule 6When process i exits its critical section, it sends a RELEASE message to all processes in Si., after deleting its own request from its own queue.
Resource Allocation > Distributed Mutual Exclusion > Quorum-Based >
Maekawa
39Slide40
Maekawa
AlgorithmRule 7Upon receiving a RELEASE message from process i, process j deletes i’s request from its queue. If there are remaining requests,
j locks itself for the most preceding request and sends a LOCKED message to process k
, the request’s originator. If there are no remaining requests,
j
unlocks itself.
Resource Allocation > Distributed Mutual Exclusion > Quorum-Based >
Maekawa
40Slide41
Complexity of
Maekawa AlgorithmParameters:K: size of quorumsT: message transmission timeE: critical section execution timeMessage complexity (best case): 3(K – 1)
K – 1 request messagesK
– 1 locked messages
K
– 1 release messages
Response time (under light competition): 3T + E
Transmission time for request messages
Execution time of current critical section
Transmission time for release messages
Transmission time for locked messages
Resource Allocation > Distributed Mutual Exclusion > Quorum-Based >
Maekawa
41Slide42
Maekawa
ExerciseN = 4, hence K = 2SC = {C, D, E}SD = {C, D, F}SE = {C, E, F}
SF = {D, E, F}
Resource Allocation > Distributed Mutual Exclusion >
Quorum-Based >
Maekawa
42
C
D
E
FSlide43
E
has received a LOCKED message from every member of SE and enters its critical section
Maekawa
Example
Resource Allocation > Distributed Mutual Exclusion >
Quorum-
Based >
Maekawa
43
F
req
(1,1)
C
D
E
req
(1,1)
req
(1,2)
req
(1,2)
locked
locked
locked
locked
locked
failed
inquire
relinquish
release
release
RQ
F
= {(1,2)}
RQ
D
= { }
RQ
E
= {(1,2)}
RQ
C
= {(1,2)}Slide44
Show why D will enter its critical section after E
Maekawa
Exercise
Resource Allocation > Distributed Mutual Exclusion >
Quorum-
Based >
Maekawa
44
F
req
(1,1)
C
D
E
req
(1,1)
req
(1,2)
req
(1,2)
RQ
F
= { }
RQ
D
= {(1,1)}
RQ
E
= {(1,2)}
RQ
C
= {
}Slide45
F queues E’s request, locks itself, and sends a LOCKED message back to E
Maekawa
Exercise
Resource Allocation > Distributed Mutual Exclusion >
Quorum-
Based >
Maekawa
45
F
req
(1,1)
C
D
E
req
(1,1)
req
(1,2)
req
(1,2)
locked
RQ
F
= {(1,2)}
RQ
D
= {(1,1)}
RQ
E
= {(1,2)}
RQ
C
= {
}Slide46
C
queues E’s request, locks itself, and sends a LOCKED message back to E
Maekawa
Exercise
Resource Allocation > Distributed Mutual Exclusion >
Quorum-
Based >
Maekawa
46
F
req
(1,1)
C
D
E
req
(1,1)
req
(1,2)
req
(1,2)
locked
locked
RQ
F
= {(1,2)}
RQ
D
= {(1,1)}
RQ
E
= {(1,2)}
RQ
C
= {(1,2)}Slide47
F queues D’s request and sends an INQUIRE message to E, since (1,1) < (1,2)
Maekawa
Exercise
Resource Allocation > Distributed Mutual Exclusion >
Quorum-
Based >
Maekawa
47
F
req
(1,1)
C
D
E
req
(1,1)
req
(1,2)
req
(1,2)
locked
locked
inquire
RQ
F
= {(1,1),(1,2)}
RQ
D
= {(1,1)}
RQ
E
= {(1,2)}
RQ
C
= {(1,2)}Slide48
E receives
F’s INQUIRE message
Maekawa
Exercise
Resource Allocation > Distributed Mutual Exclusion >
Quorum-
Based >
Maekawa
48
F
req
(1,1)
C
D
E
req
(1,1)
req
(1,2)
req
(1,2)
locked
locked
inquire
RQ
F
= {(1,1),(1,2)}
RQ
D
= {(1,1)}
RQ
E
= {(1,2)}
RQ
C
= {(1,2)}Slide49
C
queues D’s request and sends an INQUIRE message to E, since (1,1) < (1,2)
Maekawa
Exercise
Resource Allocation > Distributed Mutual Exclusion >
Quorum-
Based >
Maekawa
49
F
req
(1,1)
C
D
E
req
(1,1)
req
(1,2)
req
(1,2)
locked
locked
inquire
inquire
RQ
F
= {(1,1),(1,2)}
RQ
D
= {(1,1)}
RQ
E
= {(1,2)}
RQ
C
= {(1,1),(1,2)}Slide50
E has received a LOCKED message from every member of S
E and enters its critical section
Maekawa
Exercise
Resource Allocation > Distributed Mutual Exclusion >
Quorum-
Based >
Maekawa
50
F
req
(1,1)
C
D
E
req
(1,1)
req
(1,2)
req
(1,2)
locked
locked
inquire
inquire
RQ
E
= {(1,2)}
RQ
C
= {(1,1),(1,2)}
RQ
D
= {(1,1)}
RQ
F
= {(1,1),(1,2)}Slide51
E receives
C’s INQUIRE message
Maekawa
Exercise
Resource Allocation > Distributed Mutual Exclusion >
Quorum-
Based >
Maekawa
51
F
req
(1,1)
C
D
E
req
(1,1)
req
(1,2)
req
(1,2)
locked
locked
inquire
inquire
RQ
E
= {(1,2)}
RQ
C
= {(1,1),(1,2)}
RQ
D
= {(1,1)}
RQ
F
= {(1,1),(1,2)}Slide52
E
exits its critical section, deletes its own request, and sends RELEASE messages to SE (C and F)
Maekawa
Exercise
Resource Allocation > Distributed Mutual Exclusion >
Quorum-
Based >
Maekawa
52
F
req
(1,1)
C
D
E
req
(1,1)
req
(1,2)
req
(1,2)
locked
locked
inquire
inquire
release
release
RQ
E
= {
}
RQ
C
= {(1,1),(1,2)}
RQ
D
= {(1,1)}
RQ
F
= {(1,1),(1,2)}Slide53
F
receives E’s RELEASE message, deletes (1,2) from its queue, and sends a LOCKED message to D
Maekawa
Exercise
Resource Allocation > Distributed Mutual Exclusion >
Quorum-
Based >
Maekawa
53
F
req
(1,1)
C
D
E
req
(1,1)
req
(1,2)
req
(1,2)
locked
locked
locked
inquire
inquire
release
release
RQ
E
= {
}
RQ
C
= {(1,1),(1,2)}
RQ
D
= {(1,1)}
RQ
F
= {(1,1)}Slide54
C
receives E’s RELEASE message, deletes (1,2) from its queue, and sends a LOCKED message to D
Maekawa
Exercise
Resource Allocation > Distributed Mutual Exclusion >
Quorum-
Based >
Maekawa
54
F
req
(1,1)
C
D
E
req
(1,1)
req
(1,2)
req
(1,2)
locked
locked
locked
locked
inquire
inquire
release
release
RQ
E
= {
}
RQ
C
= {(1,1)}
RQ
D
= {(1,1)}
RQ
F
= {(1,1)}Slide55
D
has received a LOCKED message from every member of SD and enters its critical section
Maekawa
Exercise
Resource Allocation > Distributed Mutual Exclusion >
Quorum-
Based >
Maekawa
55
F
req
(1,1)
C
D
E
req
(1,1)
req
(1,2)
req
(1,2)
locked
locked
locked
locked
inquire
inquire
release
release
RQ
E
= {
}
RQ
C
= {(1,1)}
RQ
D
= {(1,1)}
RQ
F
= {(1,1)}Slide56
Resource Allocation
Distributed mutual exclusionPermission-based (Ricart & Agrawala)Quorum-based (Maekawa)Token-based (Raymond)Deadlocks
Deadlock properties (Holt)Distributed deadlock detection (Singhal)
Resource Allocation
56Slide57
Distributed Mutual Exclusion:
Token-based AlgorithmsCS/CE/TE 6378 Advanced Operating SystemsSlide58
Token-Based Algorithms
Algorithms that ensure mutual exclusion by using a special token to represent permissionWhenever a process requests a resource, it must request for the token to be passed from the current token holder to itselfA process can enter its critical section upon receiving the tokenResource Allocation > Distributed Mutual Exclusion > Token-Based
58Slide59
Raymond Algorithm
AssumptionsEvery message is eventually delivered (i.e., lossless network)Node failure can be detected and failed nodes are removedProcesses are arranged in a directed treeOne process starts with the PRIVILEGE token
Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
59Slide60
Quiz Question
What would happen if one node is not chosen as the privileged node during initialization?DeadlockMutual exclusionNode failureStarvationResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
60Slide61
Raymond Algorithm
Each process maintains the following variables:HOLDERPoints to the neighbor that holds or is closest to the tokenUSINGIndicates if the process is in its critical section
REQUEST_Q A FIFO queue that holds the names of neighbors that have sent requests for the token
ASKED
Indicates if a request has already been sent by this process
Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
61Slide62
Quiz Question
Which of the following variables creates directed tree edges?ASKEDHOLDERREQUEST_QUSINGResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
62Slide63
Raymond Example
Processes arranged in a directed treeP1 starts with tokenResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
63
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[ ]
[ ]
[ ]
[ ]
[ ]Slide64
Raymond Algorithm
Rule 1: Requesting Critical Sectionif(HOLDER == self) {
ASKED = false
;
USING
= true; // enter critical
section
}
else {
REQUEST_Q.push_back
(self)
;
if
(!ASKED)
{
send
REQUEST to HOLDER
;
ASKED
= true
;
}
}
Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
64Slide65
Raymond Example
P4 requests critical section and is not the holderResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
65
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[ ]
[ ]
[ ]
[ ]
[ ]Slide66
Raymond Example
P4 inserts its request into its REQUEST_QResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
66
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[ ]
[4]
[ ]
[ ]
[ ]Slide67
Raymond Example
P4 sends a request to the HOLDER (P2)Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
67
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[ ]
[4]
[ ]
[ ]
[ ]Slide68
Raymond Algorithm
Rule 2: Receiving RequestsREQUEST_Q.push_back(requestor);
if(HOLDER == self && !USING)
{
HOLDER =
REQUEST_Q.pop_front
();
ASKED
= false
;
send
PRIVILEGE to HOLDER
;
}
else if
(HOLDER != self && !ASKED)
{
send
REQUEST to HOLDER
;
ASKED
= true
;
}
Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
68Slide69
Raymond Example
P2 receives P4’s request and is not the holderResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
69
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[ ]
[4]
[ ]
[ ]
[ ]Slide70
Raymond Example
P2 inserts P4’s request into its REQUEST_QResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
70
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[4]
[ ]
[ ]
[4]
[ ]
[ ]
[ ]Slide71
Raymond Example
P2 sends a request to the HOLDER (P1)Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
71
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[4]
[ ]
[ ]
[4]
[ ]
[ ]
[ ]Slide72
Raymond Example
P1 receives P2’s request and is the holder
Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
72
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[4]
[ ]
[ ]
[4]
[ ]
[ ]
[ ]Slide73
Raymond Example
P1 queues P2’s requestResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
73
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[4]
[2]
[ ]
[4]
[ ]
[ ]
[ ]Slide74
Raymond Example
But then immediately pops it as the HOLDERResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond74
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[4]
[ ]
[ ]
[4]
[ ]
[ ]
[ ]Slide75
Raymond Example
P1 sends the token to the new HOLDER (P2)Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
75
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[4]
[ ]
[ ]
[4]
[ ]
[ ]
[ ]Slide76
Raymond Algorithm
Rule 3: Receiving the TokenHOLDER = REQUEST_Q.pop_front
();
ASKED
= false
;
if
(HOLDER == SELF)
{
USING
= true; // enter critical
section
}
else {
send
PRIVILEGE to HOLDER
;
if
(!
REQUEST_Q.empty
())
{
send
REQUEST to HOLDER
;
ASKED
= true
;
}
}
Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
76Slide77
Raymond Example
P2 receives the token from P1Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
77
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[4]
[ ]
[ ]
[4]
[ ]
[ ]
[ ]Slide78
Raymond Example
P2 pops P4 as the HOLDERResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
78
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[ ]
[4]
[ ]
[ ]
[ ]Slide79
Raymond Example
P2 sends the token to the new HOLDER (P4)Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
79
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[ ]
[4]
[ ]
[ ]
[ ]Slide80
Raymond Example
P4 receives the token from P2Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
80
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[ ]
[4]
[ ]
[ ]
[ ]Slide81
Raymond Example
P4 pops itself as the HOLDERResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
81
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[ ]
[ ]
[ ]
[ ]
[ ]Slide82
Raymond Example
P4 then enters its critical sectionResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
82
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[ ]
[ ]
[ ]
[ ]
[ ]Slide83
Raymond Example
P6 requests critical section and is not the holderResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
83
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[ ]
[ ]
[ ]
[ ]
[ ]Slide84
Raymond Example
P6 inserts its request into its REQUEST_QResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
84
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[ ]
[ ]
[ ]
[6]
[ ]Slide85
Raymond Example
P6 sends a request to the HOLDER (P3)Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
85
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[ ]
[ ]
[ ]
[6]
[ ]Slide86
Raymond Example
P3 receives P6’s request and is not the holderResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
86
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[ ]
[ ]
[ ]
[6]
[ ]Slide87
Raymond Example
P3 inserts P6’s request into its REQUEST_QResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
87
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[6]
[ ]
[ ]
[6]
[ ]Slide88
Raymond Example
P3 sends a request to the HOLDER (P1)Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
88
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[6]
[ ]
[ ]
[6]
[ ]Slide89
Raymond Example
P1 receives P3’s request and is not the holderResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
89
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[6]
[ ]
[ ]
[6]
[ ]Slide90
Raymond Example
P1 inserts P3’s request into its REQUEST_QResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
90
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[3]
[6]
[ ]
[ ]
[6]
[ ]Slide91
Raymond Example
P1 sends a request to the HOLDER (P2)Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
91
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[3]
[6]
[ ]
[ ]
[6]
[ ]Slide92
Raymond Example
P2 receives P1’s request and is not the holderResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
92
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[3]
[6]
[ ]
[ ]
[6]
[ ]Slide93
Raymond Example
P2 inserts P1’s request into its REQUEST_QResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
93
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[1]
[3]
[6]
[ ]
[ ]
[6]
[ ]Slide94
Raymond Example
P2 sends a request to the HOLDER (P4)Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
94
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[1]
[3]
[6]
[ ]
[ ]
[6]
[ ]Slide95
Raymond Example
P3 requests critical section and is not the holderResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
95
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[1]
[3]
[6]
[ ]
[ ]
[6]
[ ]Slide96
Raymond Example
P3 inserts its request into its REQUEST_QResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
96
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[1]
[3]
[6|3]
[ ]
[ ]
[6]
[ ]Slide97
Raymond Example
P3 does not send a request to the HOLDER since it has already ASKEDResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
97
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[1]
[3]
[6|3]
[ ]
[ ]
[6]
[ ]Slide98
Raymond Example
P4 receives P2’s request and is the holderResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
98
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[1]
[3]
[6|3]
[ ]
[ ]
[6]
[ ]Slide99
Raymond Example
P4 queues P2’s request and nothing elseResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
99
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[1]
[3]
[6|3]
[2]
[ ]
[6]
[ ]Slide100
Raymond Algorithm
Rule 4: Exiting Critical SectionUSING = false
;if
(!
REQUEST_Q.empty
())
{
HOLDER
=
REQUEST_Q.pop_front
()
;
ASKED
= false
;
send
PRIVILEGE to HOLDER
;
if
(!
REQUEST_Q.empty
())
{
send
REQUEST to HOLDER
;
ASKED
= true
;
}
}
Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
100Slide101
Raymond Example
P4 exits its critical section and its REQUEST_Q is not emptyResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
101
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[1]
[3]
[6|3]
[2]
[ ]
[6]
[ ]Slide102
Raymond Example
P4 pops P2 as the HOLDERResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
102
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[1]
[3]
[6|3]
[ ]
[ ]
[6]
[ ]Slide103
Raymond Example
P4 sends the token to the new HOLDER (P2)Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
103
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[1]
[3]
[6|3]
[ ]
[ ]
[6]
[ ]Slide104
Raymond Example
P2 receives the token from P4Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
104
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[1]
[3]
[6|3]
[ ]
[ ]
[6]
[ ]Slide105
Raymond Example
P2 pops P1 as the HOLDERResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
105
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[3]
[6|3]
[ ]
[ ]
[6]
[ ]Slide106
Raymond Example
P2 sends the token to the new HOLDER (P1)Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
106
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[3]
[6|3]
[ ]
[ ]
[6]
[ ]Slide107
Raymond Example
P1 receives the token from P2Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
107
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[3]
[6|3]
[ ]
[ ]
[6]
[ ]Slide108
Raymond Example
P1 pops P3 as the HOLDERResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
108
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[6|3]
[ ]
[ ]
[6]
[ ]Slide109
Raymond Example
P1 sends the token to the new HOLDER (P3)Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
109
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[6|3]
[ ]
[ ]
[6]
[ ]Slide110
Raymond Example
P3 receives the token from P1Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
110
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[6|3]
[ ]
[ ]
[6]
[ ]Slide111
Raymond Example
P3 pops P6 as the HOLDERResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
111
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[3]
[ ]
[ ]
[6]
[ ]Slide112
Raymond Example
P3 sends the token to the new HOLDER (P6)Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
112
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[3]
[ ]
[ ]
[6]
[ ]Slide113
Raymond Example
P3 also sends a new request since its REQUEST_Q is not emptyResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
113
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[3]
[ ]
[ ]
[6]
[ ]Slide114
Raymond Example
P6 receives the token from P3Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
114
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[3]
[ ]
[ ]
[6]
[ ]Slide115
Raymond Example
P6 pops itself as the HOLDERResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
115
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[3]
[ ]
[ ]
[ ]
[ ]Slide116
Raymond Example
P6 then enters its critical sectionResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
116
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[3]
[ ]
[ ]
[ ]
[ ]Slide117
Raymond Example
P6 receives P3’s request and is the holderResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
117
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[3]
[ ]
[ ]
[ ]
[ ]Slide118
Raymond Example
P6 queues P3’s requestResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
118
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[3]
[ ]
[ ]
[3]
[ ]Slide119
Raymond Example
P6 exits its critical section and its REQUEST_Q is not emptyResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
119
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[3]
[ ]
[ ]
[3]
[ ]Slide120
Raymond Example
P6 pops P3 as the HOLDERResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
120
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[3]
[ ]
[ ]
[ ]
[ ]Slide121
Raymond Example
P6 sends the token to the new HOLDER (P3)Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
121
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[3]
[ ]
[ ]
[ ]
[ ]Slide122
Raymond Example
P3 receives the token from P6Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
122
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[3]
[ ]
[ ]
[ ]
[ ]Slide123
Raymond Example
P3 pops itself as the HOLDERResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
123
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[ ]
[ ]
[ ]
[ ]
[ ]Slide124
Raymond Example
P3 then enters its critical sectionResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
124
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[ ]
[ ]
[ ]
[ ]
[ ]Slide125
Raymond Example
P3 exits its critical section and its REQUEST_Q is emptyResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
125
P
1
P
6
P
4
P
7
P
5
P
2
P
3
[ ]
[ ]
[ ]
[ ]
[ ]
[ ]
[ ]Slide126
Quiz Question
What could potentially happen if request queues were ordered by node number instead of being FIFO?DeadlockMutual exclusionNode failureStarvationResource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
126Slide127
Tree Topology
Worst case:Straight lineN – 1 diameterBest case:StarO(log N) diameter
Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
127Slide128
Complexity of Raymond Algorithm
Parameters:D: diameter of the directed treeT: message transmission timeE: critical section execution timeMessage complexity:Best case: 0 (r
equestor already holding token)Worst case: 2D (D requests and D privileges) Response time (under light competition): 2DT + E
Transmission time for D request messages
Execution time of current critical section
Transmission time for D privilege messages
Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
128Slide129
Quiz Question
In the best-case scenario, what is the minimum number of messages required for a process to enter its critical section?02O(log N)2(N – 1)
Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
129Slide130
Quiz Question
In the worst-case scenario, what is the maximum number of messages required for a process to enter its critical section?02O(log N)2(N – 1)
Resource Allocation > Distributed Mutual Exclusion > Token-Based > Raymond
130