multi-resource allocation with unknown participants

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