View
35
Download
0
Category
Preview:
DESCRIPTION
Multi-resource Allocation with Unknown Participants. Ajoy K. Datta , Stéphane Devismes, François Kawala , Lawrence L. Larmore , and Maria Potop-Butucaru. K-resource Allocation. C 1. N >> M. C 2. R 1. C 3. R 2. C 4. …. C 5. R M. C 6. …. Resources. C N. Clients. - PowerPoint PPT Presentation
Citation preview
Multi-resource Allocation with Unknown Participants
Ajoy K. Datta, Stéphane Devismes, François Kawala, Lawrence L.
Larmore, and Maria Potop-Butucaru
PDAA'2011, Osaka
K-resource Allocation
December 2, 2011
C1
C2
C3
C4
C5
C6
CN
Clients
R1
… Resources
R2
RM
…
• N >> M
PDAA'2011, Osaka
K-resource Allocation
December 2, 2011
C1
C2
C3
C4
C5
C6
CN
Clients
R1
… Resources
R2
RM
…
• N >> M
• Clients don’t know each other
PDAA'2011, Osaka
K-resource Allocation
December 2, 2011
C1
C2
C3
C4
C5
C6
CN
Clients
R1
… Resources
R2
RM
…
• N >> M
• Clients don’t know each other
• Request: up to K resources
• Clients only know the IDs of the resource they request
• Request given by an oracle
R1, R2
R1, R3
R4
R2, R6, R7
PDAA'2011, Osaka
K-resource Allocation
December 2, 2011
C1
C2
C3
C4
C5
C6
CN
Clients
R1
… Resources
R2
RM
…
R1, R2
R1, R3
R4
R2, R6, R7
SAFETY: Each resource is used by at most one client at a time
PDAA'2011, Osaka
K-resource Allocation
December 2, 2011
C1
C2
C3
C4
C5
C6
CN
Clients
R1
… Resources
R2
RM
…LIVENESS:
Every request is eventually satisfied
R1, R2
R1, R3
R4
R2, R6, R7
PDAA'2011, Osaka
Related Work
• K-out-of-L Exclusion• Drinking philosophers
• Application: Peer-to-Peer systems
December 2, 2011
PDAA'2011, Osaka
Model
December 2, 2011
• Asynchronous message passing
• Reliable link
•Any client can only communicate with the resources it requests
PDAA'2011, Osaka
2-Resource Allocation
• Overview– Queues• At each resource• To store client’s requests• The request at head of the queue is satisfied
• Issue– Deadlock
December 2, 2011
C3
C1
C2
R5
PDAA'2011, Osaka
2-Resource Allocation
December 2, 2011
R1
R3R2
C1 C2
C3
PDAA'2011, Osaka
Deadlock
December 2, 2011
C2
C1
R1
C3
C2
R3
C1
C3
R2
C1 C2
C3
PDAA'2011, Osaka
Our solution
• First request: strong• (Second request: weak)• Two queues per resource: strong, weak• Resource allocated to the head of its strong
queue• Weak requests move from weak to strong
queue– Under some conditions
December 2, 2011
PDAA'2011, Osaka
Our solution
December 2, 2011
R1
C1
R2
C1,R1,Weak
PDAA'2011, Osaka
Our solution
December 2, 2011
R1
C1
R2
C1
C1,R2,Strong
PDAA'2011, Osaka
Our solution
December 2, 2011
C1
R1
C1
R2
C1
PDAA'2011, Osaka
Our solution
December 2, 2011
C1
R1
C1
R2
C1
StrongReady
PDAA'2011, Osaka
Our solution
December 2, 2011
C1
R1
C1
C1
R2
PDAA'2011, Osaka
Our solution
December 2, 2011
C1
R1
C1
C1
R2
ResAllowed
PDAA'2011, Osaka
Our solution
December 2, 2011
C1
R1
C1
C1
R2
CS
PDAA'2011, Osaka
Our solution
December 2, 2011
C1
R1
C1
C1
R2
Done
PDAA'2011, Osaka
Our solution
December 2, 2011
C1
R1
C1
R2
Done
PDAA'2011, Osaka
Our solution
December 2, 2011
R1
C1
R2
EndAck
PDAA'2011, Osaka
Deadlock
December 2, 2011
C3
R3
C2C2
R2
C1C1
R1
C3
PDAA'2011, Osaka
Deadlock
December 2, 2011
C3
R3
C2
C2
R2
C1
C1
R1
C3
PDAA'2011, Osaka
Dependancy Cycle
December 2, 2011
C3
R3
C2
C2
R2
C1
C1
R1
C3
PDAA'2011, Osaka
Conflict Resolution
• Dependency cycle detection– A message follows the dependencies
• Dependency cycle breaking– A dependency is broken– A client’s request is penalized
December 2, 2011
PDAA'2011, Osaka
Fairness
• Penalization must be fair– Identifiers cannot be used
• We use a token – circulating on the resource ring
December 2, 2011
PDAA'2011, Osaka
Token (1/2)
• Token reception– The resource marks all its strong requests
• Token releasing– When all marked request have been satisfied– Forwarded to the next resource in the ring
• Each resource gets the token infinitely often
December 2, 2011
PDAA'2011, Osaka
Token (2/2)
• Token holder never penalized• Penalized dependency: – the one out-coming from the smallest non token
holder• The token holder “flushes” its “old” requests
before releasing the token
December 2, 2011
PDAA'2011, Osaka
Dynamicity
• Join– New identity
• Leave– With announcement: easy– Crash• Need a participant detector
December 2, 2011
PDAA'2011, Osaka
Participant Detector
• Required : Perfect [Fetzer,2003]
– Strong completeness: Every client that leaves tge system is eventually removed from the participant lists
– Strong accuracy: No client can be removed from a list before it leaves the system
December 2, 2011
PDAA'2011, Osaka
K > 2
• Generalized the previous solution: hard
• Pessimistic approach: prevent deadlock creation– Resource allocated sequentially– Not efficient (not enough concurrency)
• Hybrid solution ?
December 2, 2011
PDAA'2011, Osaka
Thank youDecember 2, 2011
Recommended