HAL Id: hal-00465661
https://hal.archives-ouvertes.fr/hal-00465661v3
Submitted on 11 Dec 2013
HAL
is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or
L’archive ouverte pluridisciplinaire
HAL, estdestinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires
Fair and Reliable Self-Stabilizing Communication
Colette Johnen, Ivan Lavallee, Christian Lavault
To cite this version:
Colette Johnen, Ivan Lavallee, Christian Lavault. Fair and Reliable Self-Stabilizing Communication.
Parallel Processing Letters, World Scientific Publishing, 2000, 10 (2), pp.51–59. �hal-00465661v3�
Fair and Reliable
Self-Stabilizing Communication
Colette JOHNEN
aIvan LAVALL ´ EE
bChristian LAVAULT
c∗a LRI-CNRS Universit´e Paris-Sud b LRIA-Paradis, Universit´e Paris 8
c LIPN, CNRS UPRES-A 7030, Universit´e Paris-Nord
Abstract
We assume a link-register communication model under read/write atomicity, where every process can read from but cannot write into its neighbours’ registers. The paper presents two self-stabilizing protocols for basic fair and reliable link communication primitives. The first primitive guarantees that any process writes a new value in its register(s) only after all its neighbours have read the previous value, whatever the initial scheduling of processes’
actions. The second primitive implements a “weak rendezvous” communication mechanism by using an alternating bit protocol: whenever a process consecutively writes n values (possibly the same ones) in a register, each neighbour is guaranteed to read each value from the register at least once.
Both protocols are self-stabilizing and run in asynchronous arbitrary networks. The goal of the paper is in handling each primitive by a separate procedure, which can be used as a
“black box” in more involved self-stabilizing protocols.
Keywords: Self-stabilization, communication primitive, read/write atomicity, rendezvous, liveness
1 Introduction
A self-stabilizing system which is started from an arbitrary initial configuration, regains its consistency and demonstrates legal behaviour by itself, without any outside intervention. Con- sequently, a self-stabilizing system needs not be initiated to any configuration, and can recover from transient faults. More precisely, it can recover from memory corruptions and copes with processors or channels crashes and recoverings (i.e., dynamic networks).
1.1 The Communication primitives
In the paper (see also [19]), we present fair and reliable self-stabilizing communication primitives in the link-register model. Communication between two neighbours (A and B) is carried out by the use of two sets ofcommunication registerscalled registers: rAB andrBA. ProcessA can write in the registers ofrAB and each processAandB can read from the registers ofrAB. The registers supportreadandwriteatomic operations.
∗Corresponding author: LIPN, CNRS UPRES-A 7030, Universit´e Paris-Nord, 99, Av. J.-B. Cl´ement 93430 Villetaneuse, France. Email: lavault@lipn.univ-paris13.fr
The communication primitives allow any process which writes a value in its own register (sayW rite) to make sure that every neighbour eventually reads that latter value before writing another value in the W riteregister, whatever the initial scheduling of processes’ actions. The self-stabilizing protocols for these basic communication primitives run on dynamic asynchronous arbitrary networks.
The first primitive guarantees that any processAwrites a new value in its register(s)W riteAB
only after its neighbour B has read the previous value. Notice that when A writes n times the same value consecutively in the register W riteAB, the primitive ensures thatB eventually copies this value at least once. This primitive simulates self-stabilizing reliable message-passing communications in the link-register asynchronous model. It guarantees that a message, that is the value of the register W rite, is eventually received: the value is eventually known from the neighbours’ process.
Therendezvous mechanism (as defined in [16]) synchronizes communications, i.e., thewrite and read operations are performed in and from the same register. When Process A writes a value in its registerW riteAB, it cannot perform any other action until processB has completed a read operation from the register W riteAB. The second communications primitive is a self- stabilizing “weak rendezvous”. After performing a writeoperation in its registerW riteAB, the process Acannot perform but some specific actions, as long as processB has not completed a readoperation fromW riteAB. Therefore, ifAconsecutively writesnvalues (possibly the same ones) in the registerW riteAB, the primitive guarantees that B eventually copies each value at least once. Incidentally, this protocol also maintains a weak scheduling between processes in arbitrary networks: if A writes n times the same value in W riteAB, the value will be read at leastntimes.
Each such very basic primitive may prove useful as a communication “black box” in designing more involved distributed self-stabilizing protocols.
1.2 Related Works en Results
A deterministic self-stabilizing “balance-unbalance” mechanism on two processes systems under read/write atomicity is presented in [12] and in [13]. The two processes are not executing the same code. The one executes the balance code: when both processes have the same color, it changes color. The other executes the unbalance code: when both processes have not the same color, it changes color. In [12], this mechanism is used to guarantee that each process has a mutual exclusion access to a critical section, and in [13], it is used to ensure synchronization of the processes. In both cases, this mechanism provides strong synchronization: between two “actions”
of a process, the other process cannot perform but only one “action”. In [12, 13], the two processes protocol is used to design a mutual exclusion algorithm (global synchronization) on tree networks.
As claimed in [12, 13], the balance-unbalance mechanism cannot be extended to any network topology, since there exist no deterministic self-stabilizing synchronization protocols in uniform arbitrary networks. On the other hand, a self-stabilizing synchronization on unidirectional rings is provided in [10] through the deterministic token circulation mechanism: between two actions of a process its neighbours cannot perform but only one action.
Any self-stabilizing reset protocol [5, 2, 8] can be combined with the protocol in [6] to design a self-stabilizing synchronizer. General self-stabilizing synchronizers are presented e.g. in [9, 7, 20].
Global self-stabilizing synchronizers for tree networks are also proposed in [13, 3, 11]. A self- stabilizing local synchronizer, that synchronizes each node in a tree network with its neighbours is presented in [18].
In [4], Anagnostou and Hadzilacos present a self-stabilizing data link protocol under the read/write atomicity model. Their protocol uses the balance-unbalance mechanism in order to synchronize operations performed on a register (between two write operations in the register there is only onereadoperation from that register). No proof of the protocol is given in [4]. For instance, the authors do not explain how the data link protocol can guarantee starvation-freeness.
By contrast, our primitives use no balance-unbalance mechanism (but the alternating-bit mechanism in the second primitive). Thus, they can be used in any network topology.
In the recent literature, several communication problems in the message-passing model have been addressed. A self-stabilizing communication protocol for two-way handshake is presented in [15], and a self-stabilizing version of the alternating-bit protocol is given in [1].
Section 2 describes our model with the basic assumptions. In Section 3, we present the general principle of our solution for a two processes system. The generalization to nprocesses in arbitrary networks yields the Read Checking self-stabilizing protocol, which is presented in Section 4. Section 5 is devoted to the proof of liveness and correctness of the Read Checking protocol. Section 6 presents the weak rendezvous protocol. Finally, the paper ends with few concluding remarks.
2 Model and Requirements
Although distinct from the one described in [12], our model relies on close requirements and as- sumptions, especially in terms of communication (e.g., link registers, read/write atomicity, etc.).
A distributed system consists ofnprocesses denotedA, B, etc. Each process resides on a node of the system’scommunication graph (ornetwork). Two processes which reside on two adjacent nodes of the network are calledneighbours. We model distributed self-stabilizing systems as a set of (possibly infinite) state machines called processes. Each process can only communicate with the subset of processes consisting of its neighbours. We assume alink-register communica- tion model under read/write atomicity [12]. Each link between any two neighboursAand B is composed of two pairs of registers1, denoted (W riteAB, ReadAB) and (W riteBA, ReadBA), and belonging to Aand B, respectively. Process Acan read from the two registers of B, W riteBA
and ReadBA, but cannot write into them. Similarly, process A cannot write but in its own registers,W riteAB andReadAB, to communicate withB.
A configuration of the system is the vector of states of all processes. The state of a process is the value of its internal variables and the contents of its registers.
2.1 Schedulers, Demons and Computation
An atomic step is the “largest” step which is guaranteed to be executed uninterruptedly. A process uses read/writeatomicity if each atomic step contains either a single read operation or a single write operation but not both. The system behaviour is modelled by the interleaving model in which processes are activated by a scheduler. The scheduler is regarded as a fairad- versary: in a self-stabilizing system, all possible fair executions are required to converge to a correct behaviour. A fair scheduler shall eventually activate any process which may continu- ously perform an action. A common scheduler activates either processes one by one (central demon) or subsets of processes (distributed demon). Under read/write atomicity, both central and distributed schedulers/demons are “equivalent”, in the sense that any execution performed
1In our model, the registers are physical (hardware) devices. Reading from or writing inoneregister is an atomic action according to the design of the microprocessor.
under a distributed scheduler may be simulated by a central one. A process which can perform an atomic step into a configurationc, is said to be enabled at c. During a computation step, one or more processes execute an atomic step. Acomputationof a protocol P is a sequence of configurationsc1, c2, . . .such that, fori= 1,2, . . ., the configurationci+1 is reached fromci by one computation step. A computation is said to bemaximaleither if the sequence is infinite, or if it is finite and no process is enabled in the final configuration. Aproblemis a predicate defined on computations.
2.2 Self-Stabilization
The protocol P is self-stabilizing for the problem Π if and only if there exists a predicate L defined on configurations such that
all computations reach a configuration that satisfiesL(convergence) and all computations, from L, satisfy problem Π (correctness).
Notice that the maximal computations of a self-stabilizing protocol may be finite; in that case the algorithm is said to besilent[14]. Most self-stabilizing algorithms which build spanning tree or elect a leader are silent [17]. Self-stabilizing protocols offers full and automatic protection against all transient process failures, no matter how much the data have been corrupted: e.g., all registers values may be fully corrupted.
So, whatever the registers values, our protocols secure the transfer of information between any two pair of neighbours after a “certain delay time”.
3 Principle of the Solution
Let a two processes system, consisting in two neighbouring processes A and B equipped with their two pairs of registers (see Section 2). The principle of the solution for A relies on the following basic idea. Under read/write atomicity,Asystematically keeps reading the value from W riteBAand copies out this value in ReadAB (i.e.,A reads the message sent byB and copies out the message inReadAB to informBthat its message is received). Besides,Asystematically keeps reading the value fromReadBA and compares it to the value of W riteAB. When both values are equal, A finds out that B somehow read that value (i.e., the information has been transmitted), So it can stop reading and can write again inW riteAB.
whiletrue do
A writes inW riteAB
repeat
A reads fromW riteBA;
A writes out the value ofW riteBAintoReadAB; A reads fromReadBA
until ReadBA=W riteAB
endwhile
Fig. 1. The basic 2-processes protocol forA.
AfterAhas written a new value inW riteAB,Abecomes “weakly locked” untilBreceives the message (ReadBA =W riteAB). WhenA is inside therepeat loop, it can only perform some actions, for instance,Acannot write in its registerW riteAB.
In a self-stabilizing setting, A may then proceed with the execution of its own code, since the protocol makes it sure that B did read the value from W riteAB (at least, it results from the protocol thatAknows for sure that the values inReadBAandW riteAB are identical). The corresponding code sequence forBis of course fully symmetrical to the basic protocol forA: the roles ofAandB (i.e. the registers’ names) have simply to be inverted within the above protocol in Fig. 1. Thus, a two-way communication is established betweenAandB.
4 The Protocol in Arbitrary Networks
The generalization of the above protocol to a system ofn >2 processes constituting an arbitrary network is now easy. We still assume each pair of neighbouring processes in the network to be equipped with its two pairs of registers on their common link. In order to simplify the use of variables, we call“message” the “information” exchanged between neighbours during the execution of the protocol.
A protocol which stabilizes on a single link may not generalize to a protocol which stabilizes on all links of a (finite) network, e.g. by having each process execute the “link-protocol” in a round robin manner on each individual link adjacent to it. Taking then-processes system pair by pair may cause a deadlock: for alli∈ {0, . . . , n−1},Aimay be waiting forAi+1to read from W riteAiAi+1, withAn=A0.
4.1 Notation
Write register for A: ReadABiis the register in whichAwrites the value of the last message read byAand sent byBi.
Read register for A: W riteBiA is the register in which Bi writes the message to be transmitted toA, andReadBiA is the register in whichBi writes the value of the last message read byBi and sent byA.
Write and read register for A: W riteABi is the register in whichA writes the value of the message which is to be sent to itsith neighbourBi.
Function geti for A: geti takes no argument and returns the next message to be sent to theith neighbour ofA(geti is a helper function added toA).
4.2 The Read Checking Protocol
On the same assumptions for the model (read/write atomicity) and for the scheduler’s actions (rules of activations of processes and fairness) as given in Section 2, the specification of the self- stabilizing Read Checking protocol in arbitrary networks for a processA, with neighboursBi’s (1≤i≤NA), is as follows.
constant NA : the number of neighbours ofA;
var si : message to be sent to theith neighbour ofA;
ri : message sent from the ith neighbour ofA;
vali : value of the last message sent fromAand read by theith neighbour ofA;
whiletrue do
for i= 1 to NA do write(W riteABi, geti);
endfor repeat
for i= 1 to NA do ri←read(W riteBiA);
write(ReadABi, ri);
vali←read(ReadBiA);
si←read(W riteABi);
endfor
until (∀i∈[1, NA] vali =si ) endwhile
Fig. 2.The Read Checking protocol forA.
5 Proof of the Read Checking Protocol
5.1 Proof of Liveness
Lemma 5.1 Let γ be any configuration of an arbitrary network of processes on which the read checking protocol is performed. All processes are enabled in configurationγ.
Proof. LetAbe a process, its program counter is such that
either Ais not in therepeatloop, and henceAcan write into one of itsWriteregisters;
or Ais in therepeatloop, and henceAcan either read from one of its neighbours’ register, or write into one of itsReadregisters. Thus, in any configuration,Acan perform an atomic step
(if chosen by the scheduler).
Lemma 5.2 Every execution of the protocol on any arbitrary network is infinite.
Proof. From Lemma 5.1, whatever the current configuration, all processes can execute an action. Hence, every configuration is deadlock-free and no execution can reach a deadlock
configuration. Therefore, every execution is infinite.
Lemma 5.3 Whatever the execution, every process performs an infinite number of actions.
Proof. From Lemma 5.2, every execution is infinite. From Lemma 5.1, in each configuration that is reached every process can perform an action. The scheduling of processes’ actions is fair:
if a process can always execute an action, then the process finally performs an action. Thus, by fairness, every process is performing an infinite number of actions, whatever the execution.
Definition 5.1 Let A and B be two neighbouring processes. A is said to allow B to write iff ReadBA= WriteAB. Let A be a process and let NA denote the number of neighbours of A (NA
is the degree of A in the network).
Definition 5.2 Let A and B be two neighbouring processes. The update of the register ReadAB is the sequence of the two following actions performed by B: ri ← read(W riteAB) ; write(ReadBA, ri).
A wrong writing is a write action in the register ReadBA which is not performed within the context of an update.
The correctwriting into the register ReadBAis a write action executed within the context of an update.
Lemma 5.4 Let A be a process with its program counter in the repeat loop and let B be a neighbour of A. Whatever the current configuration and the execution, the processes system exe- cuting the protocol either eventually reaches a configuration in which B allows A to write, or A exits the repeatloop.
Proof. SupposeB never allowsAto write andAnever exits therepeatloop. ThenAnever changes the value in its registerW riteAB. Under these conditions, updating its registerReadBA
is a writing permission given toAbyB (since between the reading of the value from the register W riteABand the writing of that value inReadBA, the registerW riteABdoes not change value).
Whatever the current configuration and the execution, if the program counter of B is not within therepeatloop, it takesBless thanNBactions to enter therepeatloop. OnceBenters the loop, after 4NB actions, it updates all itsReadregisters, and thus allowsA to write.
Whatever the current configuration and the execution, if the program counter ofB is within therepeatloop, it takesBat least 4NB actions either to exit the loop, or to update its register ReadAB.
Whatever the execution, B performs an infinite number of actions (by Lemma 5.4) and eventually, eitherB allowsAto write, orA exits therepeatloop.
Lemma 5.5 After executing its first action, no process can perform a wrong writing.
Proof. Process A can perform at most one wrong writing, and it may only happen when initially its program counter is set up after reading from theWriteregister and before writing in theReadregister. Once this write action is executed, each write action ofA in a Readregister
is performed within the context of an update.
Lemma 5.6 Let A and B be two neighbouring processes. After B executes its first action, if B allows A to write, then only the writing of A in its register WriteAB may be able to cancel that permission.
Proof. Nothing but writing into the registerReadBAor into the registerW riteAB can cancel the writing permission. After B executes its first action, from Lemma 5.5 there is no wrong writing anymore. Hence, any writing into the registerReadBAis executed within the context of a register’s update. This update is such that the permission remains given toA, unlessAwrites into its registerReadBAduring the updating process or after the last update.
Theorem 5.1 Let A be a process. Whatever the execution, the system of processes which per- forms the protocol reaches a configuration in which A is not within the repeatloop anymore.
Proof. Suppose A remains within the repeat loop forever; then A never writes into its Writeregisters. Every 4NA actions,A is checking out the loop exiting condition. Whatever the execution, process A performs an infinite number of actions. Hence,A checks out the repeat loop exiting condition an infinite number of times. In particular, Atests the exit condition an infinite number of times after all its neighbours have already executed an action.
If at some test all neighbours ofAallow its writing, then, at the next test, all its neighbours keep on giving A permission to write (by Lemma 5.6). In the meanwhile, A has updated its variables ri and si, and when the test happens, the loop exiting condition is satisfied: A exits the loop.
Process A stays within the loop infinitely long in the case when, at each test, at least one neighbour does not allow its writing. Once a neighbour has allowedA to write, this neighbour cannot withdraw permission fromA. Therefore, there exists at least one neighbour of Awhich never allows A to write. Now from Lemma 5.4, this is impossible, and the theorem follows.
Therefore, the protocol is deadlock-free.
Corollary 5.1 Let A be a process. Whatever the execution, A writes an infinite number of times into all its Write registers.
Proof. IfAis out of the loop, then it takesAless thanNAactions to enter the loop. When it is within therepeatloop, then by Theorem 5.1,Acannot stay infinitely long. NAactions after exiting the loop,Awrites into all itsWriteregisters and reenters therepeatloop.
5.2 Correctness Proof of the Read Checking Protocol
Theorem 5.2 Let A and B be two neighbouring processes. After B executes its first action and after any writing in the register WriteAB, A can write in the register WriteAB only if B allows it, i.e. ReadBA=WriteAB (see Definition 5.1).
Proof. Process B is the ith neighbour of A. Between each of its two writings, A enters therepeatloop and exits the loop. Once Ais within the loop, the register W riteAB does not change value. Therepeatloop’s code is such that when the loop is exited, the value of the local variablesi ofAand the value of the registerW riteAB are equal. In the loop, the local variable ri of A takes the value of the registerReadAB. The value of the registerReadBAmay change after this assignment and before the loop is exited. Thus, when the loop is exited two distinct cases have to be considered.
1. No update of the registerReadBAhappens between the reading from that register and the loop exit. Then, si=WriteAB=vali=ReadBA, andB allows the writing ofA.
2. Writings into the register ReadBA happen between the reading from that register and the loop exit. However, the latter writings are performed within the context of updat- ing. Hence, each time the value has changed, we have that ReadBA = WriteAB and, by Lemma 5.6, the equality holds while Adoes not rewrite into the registerWriteAB.
After the writing of a value in the register W riteAB, the first primitive guarantees that A will only write in the registerW riteAB ifB allows it. In the case when the value is new,B must perform the actionread(W riteAB)to allow the writing.
Summing up the Results
1. The protocol is live: every process is updating all itsWriteregisters an infinite number of times.
2. The protocol is correct: no process can write distinct values twice in a row in itsWrite register without any previous reading from that register.
6 Weak Rendezvous Protocol
In this section, we present a self-stabilizingweak rendezvouscommunications primitive.
Recall that The rendezvous mechanism (as defined in [16]) synchronizes communication in the link-register asynchronous model of distributed system: each write or read operation is performed in and from the same register. When ProcessAwrites a value in its registerW riteAB, it cannot perform any other action until process B has completed a read operation from the registerW riteAB.
Theweak rendezvousmechanism only requires that between twowriteoperations performed by a process A in W riteAB, process B performs at least one read operation from W riteAB. Therefore, if A writes a value n consecutive times (even the same ones in each row) in the registerW riteAB, the primitive guarantees thatBcopies each of thenvalues at least one time, once the system is stabilized.
The weak rendezvous mechanism is based upon the alternating bit technique. After writing in its registerW riteAB, processAchanges the value of the bit-registerControlAB. Acan write again in the register W riteAB only after B has copied the new value of ControlAB into the registerCheckControlBA. AndB copies the value only after reading in the register W riteAB.
The liveness proof of the weak rendezvous protocol is similar to the proof of the read checking protocol. The following Theorem 6.1 proves the correctness of the weak rendezvous protocol.
Theorem 6.1 Let A and B be two neighbouring processes. After B executes its first action and after the xth (≥2) writing in the register WriteAB, B reads the value from WriteAB before the next writing in WriteAB.
Proof. As shown in Theorem 5.2, we can establish that before the xth writing in the registerW riteAB,ControlAB =CheckControlBA. After the writing in the registerW riteAB,A changes the value inControlAB and enters the repeatloop (ControlAB 6=CheckControlBA).
A stays within the loop as long as B does not copy the value of ControlAB into the register CheckControlBA. Finally,B copies the value only after reading in the registerW riteAB. The weak rendezvous protocol maintains a weak scheduling of the communication between processes in the following sense. We call aweak schedulingof the communication between process Aand all itsNAneighbours the property thatAcan write twice into its registersWriteABi, only whenever all theBi’s did read from the registerWriteABi in the meantime (1≤i≤NA).
constant NA : the number of neighbours ofA;
var ri : message sent from theith neighbour ofA;
bi : alternate bit sent from theith neighbour ofA;
ci : alternate bit sent from A to theith neighbour ofA;
li : value of the last alternate bit sent fromAand read by theith neighbour ofA;
whiletrue do
for i= 1 to NA do
write(W riteABi, geti);
ci ←read(ControlABi);
write(ControlABi,(ci+ 1) mod 2);
endfor repeat
for i= 1 to NA do ri←read(W riteBiA);
bi ←read(ControlBiA);
write(CheckControlABi, bi);
ci ←read(ControlABi);
li ←read(CheckControlBiA);
endfor
until (∀i∈[1, NA] ci=li ) endwhile
Fig. 3.The weak rendezvous protocol for A.
7 Concluding Remarks
The paper presents two very basic general protocols for the design of fair and reliable self- stabilizing communication primitives. Both protocols work in arbitrary networks and also ensure minimal scheduling properties, whatever the initial configuration of the system of processes and the activations by the scheduler.
Each primitive can be used as a “black box” by a separate protocol, handling the procedures in more involved self-stabilizing algorithms. Thus, the protocols may be modified according to the designer’s will and needs: e.g., in specific topologies of networks a weak scheduling of communications may impose fewer neighbours to read from the registers. For example, with only one neighbour, a point to point self-stabilizing pseudo-rendezvous mechanism may be completed.
Along the same lines, the protocols also simulate reliable self-stabilizing message-passing in asynchronous distributed systems.
Although the paper does not concern itself with complexity measures, it is worth mentioning that when time is measured by some appropriately defined round complexity, the stabilization time of the read checking protocol isO(1).
References
[1] Y. Afek, G.M. Brown, Self-Stabilization of the Alternating-Bit Protocol,in the Proc. of the Symposium on Reliable Distributed Systems, (1989) 80-83.
[2] Y. Afek, S. Kutten, M. Yung, Memory-efficient self-stabilization on general networks,in the Proc of the 4th International Workshop on Distributed Algorithms and Graphs (WDAG’90), LNCS 486, (Springer-Verlag 1990) 15-28.
[3] L.O. Alima, J. Beauquier, A.K. Datta, S. Tixeuil, Self-stabilization with global rooted syn- chronizers, in the Proc. of the 18th International Conference on Distributed Computing Systems, (1998) 102-109.
[4] E. Anagnostou, V. Hadzilacos, Tolerating Transcientand Permanent Failures, in Proc. of the 7th Int. Workshop on Distributed Algorithms (WDAG’93), LNCS 725, (Springer-Verlag 1993) 174-188.
[5] A. Arora, M.G. Gouda, Distributed reset,IEEE Transactions on Computers, vol. 43 (1994) 1026-1038.
[6] B. Awerbuch, Complexity of network synchronization,J. of the Association for Computing Machinery, vol. 32, No. 4 (1985) 804-823.
[7] B. Awerbuch, S. Kutten, Y. Mansour, B. Patt-Shamir, G. Varghese, Time optimal self- stabilizing synchronization,in the Proc. of the 25th Annual ACM Symposium on Theory of Computing, (1993) 652-661.
[8] B. Awerbuch, B. Patt-Shamir, G. Varghese, Self-Stabilization by Local Checking and Correc- tion,in the Proc. of the 31st Annual IEEE Symposium on Foundation of Computer Science, (1991) 268-277.
[9] B. Awerbuch, G. Varghese, Distributed program checking: a paradigm for building self- stabilizing distributed protocols,in the Proc. of the 31st Annual IEEE Symposium on Foun- dations of Computer Science, (1991) 258-267.
[10] J. Beauquier, M. Gradinariu, C. Johnen, Memory space requirements for self-stabilizing leader election protocols, in Proc. of the 18th Annual ACM Symposium on Principles of Distributed Computing, (1999) 199-208.
[11] A. Bui, A.K. Datta, F. Petit, V. Villain, Space optimal and fast self-stabilizing pif in tree networks,Technical Report RR. 98-06, LaRIA, Universit´e de Picadie (1998).
[12] S. Dolev, A. Israeli, S. Moran, Self-Stabilization of Dynamic Systems Assuming only Read/Write Atomicity,Distributed Computing, 7 (1993) 3-16.
[13] S. Dolev, A. Israeli, S. Moran, Uniform dynamic self-stabilizing leader election,IEEE Trans- actions on Parallel and Distributed Systems, 8:4 (1997) 424-440.
[14] S. Dolev, M.G. Gouda, M. Schneider, Memory requirements for silent stabilization,in Proc.
of the 15th Annual ACM Symposium on Principles of Distributed Computing, (1996) 27-34.
[15] M.G. Gouda, N. Multari, Stabilizing Communication Protocols, IEEE Transactions on Computers, 40 (1991) 448-458.
[16] C.A.R. Hoare, Communicating Sequential Processes,Communication of the ACM, vol. 21, No 8 (1978) 666-677.
[17] S.T. Huang, N.S. Chen, A self-stabilizing algorithm for constructing breadth-first trees, Information Processing Letters, 41, 1992, 109-117.
[18] C. Johnen, L.O. Alima, A.K. Datta, S. Tixeuil, Self-stabilizing neighborhood synchronizer in tree networks,in Proc. of the 19th IEEE International Conference on Distributed Computing Systems, 1999.
[19] I. Lavall´ee, C. Lavault, C. Johnen, Exorcisme ou communication fiable et ´equitable autosta- bilis´ee,RR. 001, LRIA, Universit´e Paris 8 (Jan. 1998).
[20] G Varghese, Self-stabilization by counter flushing, in Proc. of the 13th Annual ACM Sym- posium on Principles of Distributed Computing, (1994) 244-253.
