A Tree Based Algorithm fro Distributed Mutual Exclusion

1. A Tree Based Algorithm fro Distributed Mutual Exclusion Addy Gronquist 11/19/2003

2. Introduction • Developed by Kerry Raymond in 1989 • In progression: • Ricart/Agrawala : 2*(N-1) messages • Suzuki/Kasami : N messages • Maekawa : sqrt(N) messages • Raymond : log(N) messages

3. Basic Ideas • Nodes arranged as an rooted tree, whose root will periodically change • Entry to critical sections controlled by possesion of token called PRIVILEGE • Only knowledge of neighbor nodes is required via the HOLDER variable, which points to the neighbor who is on the way to the node with the TOKEN (scales well)

4. Basic Topology

5. Initialization • The algorithm requires nodes to already be set up in a tree, which can be physical topology or only logical, although physical is most efficient. • This tree must be rooted somewhere, the root node will be the initial token holder.

6. Per Node Data • HOLDER: contains either ‘self’ if a node holds the PRIVILEGE, or the name of the neighbor node in the tree whose subtree contains the PRIVILEGE • USING: a flag for whether the node is currently using the PRIVILEGE (which it must hold, of course)

7. Per Node Data (cont.) • REQUEST_Q: FIFO queue of node names, including self, that have requested the PRIVILEGE via the node • ASKED: a flag to determine if the node has requested the PRIVILEGE from its HOLDER yet (this lets us make only one request per node, later queue entries will not generate MAKE_REQUEST message)

8. Messages • ASSIGN_PRIVILEGE: this is the message where the token is passed • Conditions: HOLDER==self ^ !USING ^ REQUEST_Q != empty ^ head(REQUEST_Q) != self • Effects: HOLDER=dequeue(REQUEST_Q) , • ASKED = false , send PRIVILEGE to HOLDER • Else, if head(REQUEST_Q) == self, set USING = true and use the protected resource

9. Messages (cont.) • MAKE_REQUEST: Sent once, the first time a node recieves a request (from self or other) for the PRIVILEGE that it does not hold. • Conditions: HOLDER != self ^ REQUEST_Q != empty ^ !ASKED • Effects: ASKED = true , send to HOLDER, at HOLDER node we enqueue the name of the neighbor node the MAKE_REQUEST came from to the REQUEST_Q

10. Events • There are four events that occur in our system: • 1) A node wishes to enter critical section • 2) A node receives a request for token • 3) A node receives the token • 4) A node finishes using the token • We will discuss each in turn in the next 4 slides

11. Events (want to enter) • When a node wishes to use the protected resource, it enqueues itself onto its REQUEST_Q, then runs either ASSIGN_PRIVILEGE if it is the token holder, or MAKE_REQUEST if it is not

12. Events (receive request) • When a node receives a request from a neighbor for the token, it enqueues the neighbors name into its REQUEST_Q, then either runs ASSIGN_PRIVILEGE if it is the token holder, or runs MAKE_REQUEST if it is not, which propogates the request on towards the holder, with each node acting as a proxy for its entire subtree.

13. Events (receive PRIVILEGE) • When a node receives the PRIVILEGE token, it sets HOLDER = self, then calls either ASSIGN_PRIVILEGE or MAKE_REQUEST as above

14. Events (exit Mutex) • When a node finishes personally using the token, it sets USING = false, and then runs ASSIGN_PRIVILEGE or MAKE_REQUEST as above

15. Message Overtaking • Unlike other algorithms, this handles routing on its own (which is why using logical topolgy matching the physical topology makes this run the best), so there is little chance of message overtaking, and the algorithm is resilient to overtakes anyways, so they don’t matter

16. Proofs of Operation • Mutual Exclusion: only one node can hold at a time (or zero during token transit) • Deadlock Free: three cases • No PRIVILEGE: can’t happen • Doesn’t know to pass: ASKED and REQUEST messages ensure this is not so • Token holder doesn’t know to send: can’t happen, REQUEST_Qs along path to requesting node form the path to take and are acyclic, so no ‘looping chase’ phenomenon

17. Proofs of Operation • Starvation Imossible: Complicated proof, but based on the FIFO nature of the queueing • Message Volume: worst-case: straight line tree: O(N) regular-case: radiating star: O(log N) • Simulations have shown that the regular case is basically always the case

18. Performance Under Load • Suprising Feature: performance increases to O(1)! • Basically, every other message sent will be a PRIVILEGE, and the other half will be REQUESTS, so no PRIVILEGE goes more than two nodes without an entry, on average

19. Variations • Piggyback: Aggregate MAKE_REQUEST messages onto PRIVILEGE messages that are immediately preceding them. Works especially well under heavy load • Greedy: undo FIFO requirement, so that nodes always service themselves first. This makes us not need to send a request immediately following a token as above, but it trades fairness for inceased efficiency.

20. Node Failure • All previous discussion assumed no failures. • Failure of single node is OK, it can get all info back from neighbors using a special INQUIRE message • Failure of multiple is OK, as long as no two are adjacent, otherwise request info will be lost.