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

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

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)

Basic Topology

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.

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)

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)

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

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

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

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

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.

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

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

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

Proofs of Operation Mutual Exclusion: only one node can hold at a time (or zero during token transit) Deadlock Free: three cases 1)No PRIVILEGE: can’t happen 2)Doesn’t know to pass: ASKED and REQUEST messages ensure this is not so 3)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

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

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

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.

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.