A Dynamic Token-Based Distributed Mutual Exclusion Algorithm

Transcription

1 A Dynamic Token-Based Distributed Mutual Exclusion Algorithm Ye-n Chang, Mukesh Singhal, and Ming T. Liu Dept. of Computer and nformation Science The Ohio State University Columbus, OH , USA Abstract This paper presents a dynamic token-based mutual exclusion algorithm for distributed systems. n the algorithm, a site invoking mutual exclusion sends token request messages to a set of sites possibly holding the token as opposed to all the sites as in Suzuki et al.'s algorithm [17j. A requesr ser is used to record the identifiers of such a set of sites in the system. The algorithm is dynamic because the request set is dynamically changed as the algorithm is executed. As the size of the request set is reduced, the number of the messages exchanged per CS execution is reduced. Compared with Suzuki et al.'s algorithm, the proposed algorithm can reduce the number of the messages exchanged by 40% when the traffic is light. Finally, we discuss an interesting relationship between the token-based and non-token-based mutual exclusion algorithms. t is this relationship that has motivated us to design such a dynamic token-based algorithm. 1 ntroduction A distnbuted system consists of a collection of geographically dispersed autonomous sites connected by a communication network. The sites have no shared memory and communicate with one another by passing messages. Message propagation time delay is finite but unpredictable. n this paper, we assume that the communication subsystem is reliable and sites do not crash. To achieve mutual exclusion, concurrent access to a shared resource or the Critical Section (CS) must be synchronized such that at any time only one process can access the CS. Over the past decade, many algorithms to achieve mutual exclusion in distributed systems have been proposed. Those algorithms can be classified 'Research reported herein was supported by US. Army CECOM. Ft. Monmouth. NJ, under contract No. DPLAB07-88-K-ii003. The views. opinions, and/or hdmgs contained in this paper are those of the authors and should not be constmed as an official Department of the Army position, policy or decision. into two classes: token-based and non-token-based. n token-based algorithms [2,4, 9, 10, 13, 15, 171, only the site holding the token can execute the CS and makes the final decision on the next site to enter the CS. n nontoken-based algorithms [l, 3, 5, 6, 7, 8, 11, 14, 161, a requesting site can execute the CS only after it has received permission from each member of a subset of sites in the system, and every site receiving a CS request message participates in making the final decision. Suzuki et al.'s algorithm [17] is one of the wellknown token-based algorithms. n this algorithm, a site invokmg mutual exclusion sends a Request message to every other site if it does not hold the token. However, it is not necessary for a requesting site to send a Request message to every other site in order to search for the token. A requesting site can get the token when those sites whch are possibly holding the token receive such Request messages. n this paper, we present a dynamic token-based mutual exclusion algorithm for distributed systems. n this algorithm, a request ser is used to record the identifiers of those sites which are possibly holding the token. Therefore, a site invoking mutual exclusion sends Request messages only to the sites whose identifiers are in its request set, instead of sending Request messages to all other sites in the system. The algorithm is dynamic because the request set is dynamically changed as the algorithm is executed. As the size of the request set is reduced, the number of the messages exchanged per CS execution is reduced. Compared with Suzuki et al.'s algorithm, the proposed algorithm can reduce the number of the messages exchanged by 40% when the traffic is light. Finally, we discuss an interesting relationship between the token-based and non-token-based mutual exclusion algorithms. t is this relationshp that has motivated us to design such a dynamic token-based algorithm. The rest of the paper is organized as follows. n the next section, we present the algorithm. n Section 3. we prove the correctness of the algorithm. n Section 3, we study the performance of the algorithm. n Section 5. CH2859-5/91/0000/0240$ EEE 240

2 we discuss several extensions to the proposed algorithm. n Section 6, we discuss an interesting relationship between the token-based algorithms and non-token-based algorithms, and describe how we discovered the dynamic token-based algorithm based on the observed relationship. Finally, Section 7 contains the concluding remarks. 2 Description of the Algorithm n the algorithm, every site maintains the information about the sites possibly holding the token. A site executes a Request-CS procedure to invoke mutual exclusion and a Request Message Handler processes the incoming Request messages. 2.1 Data Structure and nitialization At every site S, a request set Rs is used to record the identifiers of the sites possibly holding the token. To detect an out-of-date request message, a Seqs array (with N entries) at each site S and a TSeq array (with N entries) in the Token message are required. Seqs[] at site S, N, records the number of CS requests made by site as far as site S knows; TSeq[] records the number of CS executions finished by site. f TSeq[] > Seqs[] at site S, the value of Seqs[Q is out-of-date; if Seqs [U > TSeq[] at site S (i.e., SeQ[rl = TSeq[l + l), site has finished the (TSeq[]) th CS execution, and is requesting the (Seqs[]) th (= Seq~[l]) CS execution. A FFO (First-n-First-Out) queue TQ included in the Token message contains waiting requests. There are two operations on TQ: EQ(TQ, X) and DQ(TQ). An EQ(TQ, X) procedure adds the identifier of site X to TQ, and a DQ(TQ) function removes the first entry X from TQ and returns entry X as the function value. Three boolean variables are used to denote the state of a site S: Requestings, Executings, and HaveTokens. These variables are true only if a site is requesting, executing, and holding the token, respectively. nitially, every site S sets Rs to contain the identifiers of all other sites in the system, Seqs[Q = 0, N, and Requestings = Executings = HaveTokens = false. We arbitrarily choose a site X to hold the token, and sets HaveTokenx = true and R,y = The Algorithm Site S executes the Request-CS procedure, shown in Figure 1 (where the underlined statements show how R is updated and used as the algorithm is executed), to invoke mutual exclusion. n the request phase, site S checks whether it holds the token by testing the procedure Request-CS; besin (* the request phase *) Requesting = true; if (not HaveToken) then Seq[S] = Seq[Sl + 1; for every Y E R do send a RequestG Seq[S]) message to site Y; wait until the Token(TQ, TSeq) is received; R = 4; HaveToken = true; Requesting = false; (* the execution phase *) Executing = true; enter the CS; ExecuMg = false; (* the release phase *) TSeq[S] = Seq[S]; for X = 1 to N do if ((not (X E TQ)) and (Seq[Xl = TSeqp] + 1)) then EQ(TQ, X); for every Y in TQ do R = R U {Y}; if (TQ # 4) then HaveToken = false; Y = DQTQ); send a Token(TQ, TSeq) message to site Y; Figure 1: Request-CS procedure HaveTokens flag. f site S does not hold the to increases ts sequence number by 1 and includes t quence number in each Request message to every whose identifier is in Rs. After site S receives the ken(tq, TSeq) message, it resets Rs to empty and enters the execution phase. n the release phase, site S updates its number in the TSeq array included in the Toke to inform other sites that it has hshed the (Seqs[S]) th CS execution. Then, site S checks whether there is any new request, and adds these new requests to TQ. For those sites whose identifiers are in TQ, they are the sites possibly holding the token after site S sends out the token. Therefore, every entry in TQ is recorded Rs. f there is any waiting request Y in TQ, site S set HaveTokens = false, and sends the token to site Y n the Request Message Handler, shown 2, site S takes different action depending on it state. f this is an out-of-date request, i.e., Seqs[W, then site S ignores the request. Otherwise, if site S holds the token and is not executing the CS, 241

3 procedure Request-Handler; (* for Request(X, XSeq) message *) if (XSeq > Seq[Xj) then SeqCX] = XSeq; if ((HaveToken) and (not (Executing)) and (Seq[W = TSeq[W + 1)) then HaveToken = false; send a TokenflQ, TSeq) message to site X; end else if ((Requesting) and (not(x E R))) then send a Request(S, Seq[S]) message to site X: f (not (X E R)) then R = R U {X}; Figure 2: Request Message Handler it sets HaveTokens = false and sends the token to site X; (2) if site S is requesting the CS and has not sent a Request message to site X, it sends a Request message to site X. n both cases, site X can be the site holding the token before site S enters the CS; therefore, site S adds the identifier of site X to Rs. 3 Correctness n this section, we show that the algorithm achieves mutual exclusion and is free from deadlock and starvation. 3.1 Mutual Exclusion To show that the algorithm achieves mutual exclusion, we have to prove that at most one site holds the token. nitially, only one site holds the token, say site S. There are two situations where site S sends the token to another requesting site: (1) after site S 6nishes execution of the CS and TQ # 9; (2) when site S is not executing and one Request message is received. n either case, site S sends the token to only one site and resets the HaveToken flag to false before it sends out the token. Therefore, at most one site holds the token. 3.2 Freedom from Deadlock A system of sites is said to be in deadlock when no site is executing the CS and no requesting site can ever execute the CS. To show that such a situation never occurs and a requesting site eventually gets the token, the following two conditions must hold: 1. A request will rutive at a site holding the token. Set S Figure 3: The system Set S3 Token 2. A site holding the token will send the token to a requesting site in finite time. To prove that condition 1 holds in the algorithm, we use the following lemmas: Lemma 1: Site X s request will arrive at site Y which holds the token before site X gets the token if('ti i, j, i E R, or j 5 R, when site X invokes mutual e.dusion. Proof: The condition ('i, j) i 5 R, or j E R, implies that the system can be considered as a union of three disjoint sets (denoted as S1, S2 and S3) as shown in Figure 3: S1 = {X}, S2 = {Y Y E R,y}, and S3 = {Zl X E Rz}. Note that when a site Y holds the token. RY = 4 (i.e., the identifier of site X cannot be in Ry). Therefore. when site X's request arrives at site Y (Y E S2), the token can be held at site Y (Y E S2) or has been sent to site 2 (Z E S3) from site Y (Y 5 S2). n the case that the token is still held at site Y (Y E S2), site X's request will arrive at the site holding the token. n the case that the token has been sent to site 2 (Z E S3) from site Y (Y E S2), site Z must have sent a Request message to site X (due to X E Rz). When site X receives site 2's request (Z E S3), site X detects that the identifier of site Z is not in R.Y. Then, site X sends a Request message to site 2 and adds the identifier of site Z to R,y (i.e., the identifier of site 2 is removed from set S3 and added to set S2 at this moment). Consequently, in both cases, site X's request will arrive at a site holding the token. Lemma 2: (V X, Y) X E RY or Y E R,y is always satisfied in the algorithm. Proof: nitially, a site Y holding the token has Ry = 0, and every other site X has R.y containing the identitiers of all other sites in the system: therefore. the condition is satisfied initially. As the algorithm is executed, a site X can be in one of the following four states depending upon the changes to R,y : (1) site X is requesting the CS, (3) site X holds the token and is executing the CS, (3) site X has finished execution of the CS and has sent the token to another requesting site Y, and (4) site X receives a request from the other site Y. n the first case since site X is requesting the CS. the identifier of site X is added to RY ((b Y) Y E R,yh At this point, X E Ry for all other sites Y. n the second 242

4 case when site X receives the token, site X sets Rx = $J: however, X E Ry is still true for all other sites Y. Ln the third case when site X sends the token to another requesting site Y, site X adds the identifier of site Y to R,y. Therefore, for the requesting site Y which is going to hold the token (and then set RY = 4), Y E R.Y, and for the other sites Z, X E RZ still holds. n the fourth case when site X receives a request form site Y, it adds the identifier of site Y to Rx. Therefore, for those requesting sites Y which send Request messages to site X, both X E Ry and Y E R,y are true, and for the other sites Z, either X E RZ or Z E Rx remains true. Therefore, X E Ry or Y E R,y is always satisfied in the algorithm. 3 From lemma and lemma 2. a request will arrive at a site holding the token; therefore, condition 1 holds. Since all waiting requests (which can be detected from the condition Seqs[] = TSeq[] t 1 at site S) are added to TQ, and the site holding the token will send the token to the first site in TQ, condition 2 is also satisfied by the algorithm. Consequently, the algorithm is free from deadlock. 3.3 Freedom from Starvation Starvation occurs when a few sites repeatedly execute the CS while other sites wait indefinitely for their turns to do so. Ln the algorithm, a FFO (First-Ln-First-Out) queue TQ is used to contain all waiting requests detected at the site holding the token. Moreover, the token is passed around according to the order of requests in TQ. After a site Y whose request is in front of site X s request in TQ has finished execution of the CS, its subsequent request will be added to TQ after site X s request. Therefore, site X will get the token before any of the sites whose requests are in front of site X s request in TQ gets the token twice (or more). Consequently, the algorithm is free from starvation. 4 Performance n this section, we study the performance of the proposed algorithm by simulation. The performance model used in this paper is similar to the one used in [12]. We assume that requests for CS execution arrive at a site according to the Poisson distribution with parameter A. Message propagation delay between any two sites is constant (T). The time taken by a site to execute the CS is also constant (E). A site processes the requests for the CS one by one, and there is only one CS in the system number of 18 - messages O k 0 Suzuki + proposed.,.,..,.,...,.,. Simulation experiments were carried out for a homogeneous system of 21 sites (i.e., N = 21) for various values of the traffic of CS requests (A). Message propagation delay (T) between the sites was taken as 1.0, and CS execution time (E) was taken as The values of the parameters chosen here are consistent with those in [12]. Figure 4 shows the message traffic of the proposed algorithm and Suzulu et al. s algorithm [17] as a function of the arrival rate. Ln light traffic (0 5 X ). most of the time only one or no request for CS is present in the system; the algorithm needs less than 60% * N messages per CS execution. n heavy traffic, all the sites will always have a pending request for CS execution; therefore, /R = N - 1, and the algorithm needs N messages which is the same as in Suzuki et al. s algorithm. 5 Extensions We now present an improved version of the dynamic token-based mutual exclusion algorithm in whch the queue TQ included in the Token message S removed and a drfferent arbitration rule is used to determine the next site to hold the token. Moreover, we discuss different initialization of request sets in such a dynamic tokenbased algorithm. 5.1 A Dynamic Token-Based Mutual Exclusion Algorithm Without TU The queue TQ is used to record those waiting requests and stores them in a certain order (to smplify the determination of the next site to hold the token). However, the use of TQ is redundant since those waiting requests can be determined by the relationship between Seq and TSeq, and the order about the next site to hold the token can be determined by several arbitration rules [ 151. A site satisfying (Seqs[l = TSeq[] t 1) at site S, N, implies that site has a waiting request. 243

5 "(***)" means the changes to the previous algorithm *) the request phase is the same as that in Figure 1 *) the release phase *) TSeq[S] = Seq[S]; for X = 1 to N do (***) if (Seqm = TSeqCX] + 1) then (***) R = R U {X: (***) ~ %,. ~, for X = (S + 1) to N, and then 1 to (S - 1) do (***) if (Seq[W = TSeq[W + 1) then (***) bep (***) HaveToken = false; (***) send a Token(TSeq) message to site Y (***) exit; (***) (***) procedure Request-Handler; begm (* for Request(X, XSeq) message *) if (XSeq > Seq[xl) then &gin SeqM = XSeq; if ((HaveToken) and (not (Executing)) and (Seq[q = TSeq[X] + )) then HaveToken = false; send a TokenflSeq) message to site X; (***) end else if ((Requesting) and (not(x E R))) then send a Request@, Seq[S]) message to site X; f (not (X E R)) then R = R U {X; Figure 5: A dynamic token-based mutual exclusion algorithm without TQ One of the arbitrary rule is that a site can determine the next site to hold the token in a round-robin fashion, i.e., site S sends the token to a site with the lowest identifier which is higher than that of site S (with wrap around). This scheme guarantees that a site does not get the token more than once while other sites are waiting for it. The other arbitration rule is that a site can send the token to a site which has the smallest sequence number of all the requesting sites. This scheme favors the sites which have executed the CS less frequently and discourages the sites which have executed the CS frequently. Note that the ordering of requests in TQ does not reflect the order in which the corresponding sites made the requests for the CS. Therefore, the removal of TQ not only reduces the size of the Token message whch in turn reduces processing and communication overhead, but also provides the flexibility of detennining the next site to hold the token. n the algorithm, shown in Figure 5, TQ is removed from the Token message and a waiting request is detected by comparing each entry in TSeq and Seq arrays. n the release phase, if (Seqs[W = TSeq[X] + 1) at site S, then site X has a waiting request. Th~s also implies that site X possibly holds the token after site S sends out the token; therefore, the identifier of site X is added to Rs. Next, site S uses the round-robin arbitrary rule to determine the next site to get the token. The Request Message Handler is similar to the one in the algorithm presented in Section 2, except that the Token message does not include TQ information. This algorithm has similar message traffic as the dynamic token-based algorithm presented in Section 2. Ricart et al. [12] have proposed a token-based mutual exclusion algorithm which also removes the queue TQ from the Token message as opposed to Suzuki et al.'s algorithm [17]. A round-robin arbitration rule is used in Ricart et al.'s algorithm. However, in Ricart et al.'s token-based algorithm, a site involung mutual exclusion sends Request messages to all other sites, instead of a set of sites possibly holding the token as in our dynamic token-based algorithm presented in Section 5. That is, both Ricart et al.'s token-based algorithm and Suzuki et al.'s algorithm have sruric request sets which contain the identifiers of all other sites in the system. On the other hand, our two algorithms presented in Sections 2 and 5 have dynamic request sets, thereby improving the system performance. 5.2 nitialization of Request Sets n both of the proposed dynamic token-based mutual exclusion algorithms, we initialize the request set at a site to contain the identifiers of all other sites and then update the request set to ensure that the condition (Y X, Y) X E Ry or Y E R,y is always satisticd. As proved in Section 3, X E Ry or Y E R-y is the sufficient condition to ensure that a request will arrive at a site holdmg the token in a dynamic token-based algorithm. Therefore, it is not necessary to initialize a request set to contain the identifiers of all other sites in the system. Figure 6- (a) shows an example of initializing request sets which satisfy the condition, assuming site 1 holds the token initially. Figure 6-(b) shows another example in which Rs = { 1,2,..., (S-)} and site 1 holds the token initially. n this way, if X < Y, R,y 1 Ry = { 1. 2,..., (X- )} (i.e., R,y C RY), which implies that X E Ry or Y E R,y. Therefore, many different ways of initializing request sets that satisfy the condition ('V X, Y) X E Ry or Y E R,y can be applied to our dynamic token-based algorithm. Singhal's heuristically-aided algorithm [ 151 in which the system is initialized as Figure 6-(b) is a special case of the dynamic token-based algorithm. 244

6 Figure 6: nitialization of request sets in a dynamic token-based algorithm 6 Relationship Between Token-Based and Non-Token-Based Algorithms n this section. we discuss an interesting relationship between the token-based algorithms and non-token-based algorithms, and describe how we discovered the dynamic token-based algorithm based on the observed relationship. Although different data structures and methodologies are used in non-token-based and token-based algorithms (for example, timestamps are used in non-tokenbased algorithms while sequence numbers are used in token-based algorithms), an interesting relationship between non-token-based algorithms (which do not use site locking) [l, 11, 161 and token-based algorithms (which use broadcast communication) [13, 15, 171 has been observed as shown in Figure 7. For every non-token-based algorithm, apparently there exists a token-based algorithm with the same initialization of request sets and similar rules to update request sets. For example, both Ricart et al. s non-token-based algorithm [l l] and Suzuki et al. s token-based algorithm [71 use sratic request sets which contain the identifiers of all other sites in the system; both Singhal s dynamic information structure algorithm [16] and Singhal s heuristically-aided algorithm [ 151 use dynamic request sets which are initializedas Rs = (1, 2, -.-,(S-l)}. This relationship prompted us to search for a token-based algorithm which has the same initialization of request sets and similar rules to update request sets as Carvalho et al. s algorithm [l]. That is how we discovered such a dynamic token-based algorithm. As compared to Ricart et al. s non-token-based algorithm [ll], Carvalho et al. s algorithm [l] has avoided some unnecessary Request and Reply messages by using the implicit no-request message strategy. n this algorithm, if site X has not received a Request message from site Y since site X executed the CS last time. it implies that site Y is not requesting the CS and has given its permission to site X. Therefore, site X does not have to ask for pemssion from site Y, and message traffic is reduced. To achleve this purpose, a boolean array A is used and dynarmcally updated at each site such that it records the identifiers of a set of sites which are not requesting the CS. (Note that the boolean may A used in Carvalho et al. s algonthm has the sirmlar function as the request set R used m our dynamic token-based algorithm.) Moreover, the relationshp among Suzuki et al. s algonthm [ 171, the proposed dynamic token-based algonthm, and Smghal s hemstically-aided algorithm [15] is similar to the relationship among Ricart et al. s nontoken-based algorithm [ 111, Carvalho et al. s algorithm [l], and Singhal s dynamic information structure algonthm [16]. That S, the proposed dynamic token-based algonthm improves Suzuki et al. s algorithm by applying the implicit no-token strategy. n the proposed dynamic token-based algonthm, d a site Y has not requested for the token since site X executed the CS last time, it implies that site Y will not hold the token and site identifier Y should not be in R,y. n other words, if site Y acquires the token after site X has finished execution of the CS recently, site Y may hold the token and its identifier should be in R,y. This implicit no-token strategy is sunilar to the implicit no-request message strategy used in Carvalho et al. s algorithm [l]. Furthermore, Singhal s dynamic information structure algorithm [15] has similar strategy to reduce message traffic as that m Carvalho et al. s algonthm. However, in Singhal s dynamic information structure a rithm, the initial value of Rs is set to { 1,2,..., (Sthis algorithm can be considered as a special case of C valho et al. s algorithm. Therefore, as Singhal s dynamic information structure algorithm [16] is a special cas Carvalho et al. s algorithm, Singhal s hemstically-a algorithm [ 151 can also be considered as a special c of the proposed token-based algorithm presented in Sec tion 5. 7 Conclusions n this paper, we have proposed a dynamic token-based mutual exclusion algorithm for distributed systems. the proposed algonthm, a site invoking mutual exclu sion sends its requests to a set of sites possibly holdin the token, instead of to all other sites as in Suzuki al. s algorithm. Therefore, the number of the messag exchanged is reduced. As compared to Suzuki et al. algonthm, the proposed algorithm can reduce message traffic by 40% in light traffic, and needs N messages (which is the same as Suzuki et al. s algonthm) in heav traffic. 245

7 r Non-Toky-Based / M 1 B 4-b f Ricart & Agrawala s non- token-based dynamic R? dynamic token-based 2 1 carvalho & Roucairol 1 1 Rs=[ 1,2,..,S-l] 1 Singhal s 4 Singhal sdynamic heuristically-aided information structure A : Algorithms A and B have the same initialization of request sets and similar rules to update the requet sets. Figure 7: Relationship Between Token-based and Non-Token-based Algorithms References [] 0. S. F., Carvalho and G. Roucairol, On Mutual Exclusion in Computer Networks, Technical Correspondence, Communications of ACM, Vol. 26, No. 2, pp , Feb [2] Y.. Chang, M. Singhal and M. T. Liu, An mproved O(log N) Mutual Exclusion Algorithm, Prof. of the 19th nternational conf. on Parailel Processing, vol. 3, pp , Aug [3] Y.. Chang and M. Singhal, A Correction to Maekawa s V% Mutual Exclusion Algorithm, Technical Report, Dept. of Computer and nformation Science, The Ohio State University, Sept C4i y.. M. Singhai and M. T. Liu, A Fault Algorithm for Distributed Mutual Exclusion, Proc. of the 9th EEE Annual Symposium on Reliable Distributed Systems, pp , Oct [5] Y.. Chang, M. Singhal and M. T. Liu, A Hybrid Ap proach to Mutual Exclusion for Distributed Systems, Proc. of the 14th Annual nternational Computer SOBware and Application Conference, pp , Oct. 19W. [6] Y.. Chang, M. Singhal and M. T. Liu, A Deadlock- Free O(-) Mutual Exclusion Algorithm for Distributed Systems, to appear in the Proc. of the lnternational Computer Symposium, Dec [7] L. Lamport, Time, Clocks and Ordering of Events in Distributed Systems, Communications of ACM, Vol. 21, NO. 7, pp , July [8] M. Maekawa, A v% Algorithm for Mutual Exclusion in Decentralized Systems, ACM Trans. on Computer Systems, Vol. 3, No. 2, pp , May [9] S. Nishio, K. F. Li, and E. G. Manning, A Resilient Mutual Exclusion Algorithm for Computer Network, EEE Tran. on Parallel and Distributed Systems, Vol. 1, No. 3, pp , July [ 101 K. Raymond, A Tree-Based Algorithm for Distributed Mutual Exclusion, ACM Trans. on Computer Systems, Vol. 7, No. 1, pp , February [ 111 G. Ricart and A. K. Agrawala, An Optimal Algorithm for Mutual Exclusion in Computer Networks. Communications of ACM, Vol. 24, No. 1, pp. 9-17, Jan [12] G. Ricart and A. K. Agrawala, Performance of a Distributed Network Mutual Exclusion Algorithm, Tech. Rep. TR-774, Dept. Computer Science, Univ. of Maryland, College Park, MD. March [ 131 G, Ricart and A. K, Agmwala, Author s Response to On Mutual Exclusion in Computer Networks. Techmcai Comspondence, Communications of ACM, Vol. 26, No. 2, pp , Feb [14] B. A. Sanders, The nformation Structure of Distributed Mutual Exclusion Algorithms. ACM Trans. on Computer Systems, Vol. 5, No. 3, pp , August [ 151 M. Singhal, A Heuristically-Aided Algorithm for Mutual Exclusion in Distributed Systems, EEE Trans. on Computers. Vol. 38, No. 5, pp , May [ 161 M. Singhal, A Dynamic lnformation Smcture Mutual Exclusion Algorithm for Distributed Systems, Proc. of the 9th nternational Conf. on Distributed Computing Systems, pp , June [17]. Suzuki and T. Kasami, A Distributed Mutual Exclusion Algorithm, ACM Trans. on Computer Systems. Vol. 3, No. 4, pp , Nov