model checking simpson’s four-slot fully asynchronous

CSL Technical Report • July 3, 2002

Model Checking Simpson’s Four-Slot Fully AsynchronousCommunication Mechanism

John RushbyComputer Science LaboratorySRI InternationalMenlo Park CA 94025 USA

This research was supported by NASA Langley Research Center under contractNAS1-20334 and Cooperative Agreement NCC-1-377 with Honeywell Tucson, andby the DARPA MoBIES program under contract F33615-00-C-1700 with US AirForce Research Laboratory.

Computer Science Laboratory • 333 Ravenswood Ave. • Menlo Park, CA 94025 • (650) 326-6200 • Facsimile: (650) 859-2844

Abstract

Simpson’s four-slot fully asynchronous communication mechanism allows singlereader and writer processes to access a shared memory in such a way that interferencebetween concurrent reads and writes is avoided, the reader always accesses the most recentdata stored by the writer, and neither process need wait for the other. In computer scienceparlance, it is a means for implementing a wait-free atomic register.

We use the SAL model checking environment to examine this mechanism and show thatconcurrent reads and writes are indeed noninterfering but that access to the most recentlywritten data requires the unattractive assumption that some of the control registers are al-ready atomic. We exhibit counterexamples that reveal incorrect operation when the controlregisters are not atomic, and also when the mechanism is modified (following a suggestionof Simpson) so that control registers are written only when their values will be changed. Wedo successfully verify the algorithm when its control registers are assumed to be atomic.

The requirement for atomic control registers is unattractive: it means that any appli-cation that uses Simpson’s mechanism must be accompanied by separate, strong evidencethat its implementation of the control registers satisfies this requirement. We recommendformal examination of alternative algorithms that operate under weaker assumptions.

i

Contents

Contents iii

1 Introduction 1

2 Simpson’s Algorithm and Its Formal Examination 32.1 Formal Specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Formal Examination: Mutual Exclusion. . . . . . . . . . . . . . . . . . . 102.3 Formal Examination: Freshness. . . . . . . . . . . . . . . . . . . . . . . 112.4 Formal Examination: The Modified Specification. . . . . . . . . . . . . . 162.5 Formal Examination: Assuming Atomic Control Registers. . . . . . . . . 19

3 Conclusion 21

Bibliography 25

A Simpson’s Algorithm in SAL 29

B Modified Simpson’s Algorithm in SAL 33

C Simpson’s Algorithm with Atomic Control Registers in SAL 37

iii

Chapter 1

Introduction

Embedded control systems must often move data between subsystems that do not sharea common clock. Dual-ported memory commonly provides the interface between suchsubsystems. Because they do not share a clock, it is possible for one subsystem to bereading data from the shared memory at the same time the other is updating it. Without aprotocol to ensure some kind of controlled access, it is possible that a read concurrent witha write could obtain partially written data that appears valid but is actually incorrect, andthis could lead to incorrect and possibly unsafe operation.

One way to eliminate this danger would be to use semaphores or other locking mech-anisms to enforce mutual exclusion on the reading and writing activities: that is, only oneof them can be in progress at any one time. The problem with this approach is that oneactivity can block the other: for example, if the writer is much faster than the reader, it mayalmost always seize the lock and thereby starve the reader, or delay it beyond its deadline.Priorities, or enforced alternation, change the character of the problem, but do not eliminateit.

As described elsewhere [Rus02], the larger problem with such locking schemes is thatthey render the flow of control between componentsbidirectional. Kopetz [Kop99] definesinterfaces that involve bidirectional flow of control as “composite” and argues convincinglythat they should be eschewed in favor of “elementary” interfaces in which control flow isunidirectional. (Data flow may be bidirectional, but the task of tolerating external failures,and of application-independence, is greatly simplified by the unidirectionalcontrol flow ofelementary interfaces.)

The need for elementary interfaces leads to protocols for concurrent reading and writingthat do not use locks. One approach allows concurrent access to the same memory, but thereader is able to detect if it was changed during its operation; if so, the reader may eitherretry or reuse its previous data [Lam77]. An improvement over such “lock-free” protocolsare “wait-free” protocols that guarantee the reader immediate access to the most recentlywritten data; typically, these algorithms cause concurrent reads and writes to use differentareas of memory.

1

Development and study of protocols for concurrent readers and writers has been pur-sued separately in the real-time and computer science communities. Anderson [And01]provides a useful summary from the computer science perspective, where the work of Lam-port is particularly significant, not only in the development of protocols, but in defining theproblem and introducing methods for its analysis [Lam86].

The Time Triggered Architecture (TTA) [TTT01, KG94] uses the Nonblocking Write(NBW) protocol of Kopetz and Reisinger [KR93]. Anderson [And01] observes that theseauthors were “apparently unaware that Lamport had invented this algorithm 16 years ear-lier” (referring to the algorithm of [Lam77]). In fact, there are two parts to NBW: the firstpart is lock-free (and is the same as Lamport’s algorithm) but it is not wait-free; the secondpart adds multiple buffers to make it wait-free (and therefore truly nonblocking). The firstwait-free construction was due to Peterson [Pet87], but it assumed atomic control registers;an algorithm that eliminated this assumption was published by Burns and Peterson [BP87],and counterexamples that revealed numerous flaws in that algorithm were described byHaldar and Vidyasankar [HV92]. Correct algorithms for this problem were known in com-puter science by the late 1980’s [Tro89]. Independently, Simpson presented a different,and attractively simple algorithm [Sim90], and this is the one best known in the real-timeand avionics communities. It also provides the inspiration for the second part of the NBWconstruction.

Because its mechanisms are fundamental, because it is widely used, and because itinspires the crucial wait-free aspect of the NBW protocol, we provide a formal examina-tion of Simpson’s algorithm. This algorithm has recently also been examined formally byHenderson and Paynter [HP02]; however, they consider only mutual exclusion, and not theadditional desirable property that the reader always obtains recently written data. Further-more, they conduct their examination by theorem proving (in PVS) whereas we note that,apart from the data communicated, the algorithm is finite state and can be examined bymodel checking. Clark [Cla00] examines several algorithms, including Simpson’s, usingPetri nets; we compare this work with ours in Chapter3.

We use the SAL model checking environment to examine Simpson’s algorithm andshow that concurrent reads and writes are indeed noninterfering but that access to the mostrecently written data requires either very careful (and, we would argue, nonobvious) in-terpretation of the algorithm, or else the unwarranted assumption that some of its controlregisters are already atomic.

2

Chapter 2

Simpson’s Algorithm and Its FormalExamination

Consider two processes—a reader and a writer—that communicate via a shared memory.The two processes and the memory are asynchronous, meaning they have no common clockand there are no assumptions about their relative rates of operation. Periodically, the writerhas new data that it writes to the memory, and periodically the reader reads data from thememory. Without coordination, there is the possibility that the reader accesses the memoryat the same time the writer is updating it. It is possible that the physics of memory accessare such that concurrent reading and writing can cause the reader to obtain unpredictablevalues: for example, if a memory cell requires some time to “latch” the charge representingits state, or if the data spans several locations and must be read and written in stages. Forall these reasons, it is possible that a read concurrent with a write may obtain a value thatis only “half written.” Lamport [Lam86] distinguishes several kinds of behavior that mayobtain when memory (or “registers”) are read and written concurrently.

Safe registers return the value most recently written when a read is not concurrent witha write; when a read is concurrent with a write, they can return any value. Strictly,Lamport requires that safe registers return a value consistent with their type—thiscan always be enforced if there is some way to recognize the type; Henderson andPaynter [HP02] argue that this behavior should be calledtypesafe, and suggest thetermpersistentbe used for the weaker assumption that a read concurrent with a writecan return absolutelyanyvalue. We will use the more traditional term, but will notewhen the weaker assumption is adequate.

Regular registers return the value most recently written when a read is not concurrent witha write; when a read is concurrent with a write, or series of writes, the read may returnthe value prior to the writes, the final value written, or any of the values written bythe intermediate writes.

3

Atomic registers return the value most recently written when a read is not concurrent witha write; when a read is concurrent with a write, or series of writes, the behavior isconsistent with them occurring in some serial order. This is stronger than a regularregister in that a series of concurrent reads and writes will never cause a read to returndata older than that returned by a previous read.

The challenge, stated in computer science terms, is to find an algorithm that implementsan atomic register, using only safe registers. One plausible approach is to use two buffersor, following Simpson’s terminology, “slots” so that the writer alternates between the twoslots, and the reader accesses whichever of them isnot the target of the current write (or ofthe next write, if there is none currently active). The problem here is that if a read overlapsmultiple writes, then the second write will use the slot already being used by the reader—thus, the algorithm must be modified so that the writer avoids the slot currently used bythe reader. Several control bits are needed to coordinate the reader and the writer in thismanner, but all proposed algorithms are vulnerable to unfortunate interleavings that causethe reader and writer to access the same slot concurrently. It seems that additional slotsare necessary. Simpson [Sim90] describes a three-slot algorithm, but finds that it suffersfrom the same vulnerabilities as the two-slot algorithm, so it looks as if at least four slotsare necessary. (A three-slot algorithm can be made to work if we allow special hardware“compare-and-swap” instructions [CB97].)

Simpson’s four-slot algorithm arranges the slots as two pairs; we can call the pairsleft andright , and within each pair refer to thetop andbottom slots. The writeroperates on one pair, alternating between thetop andbottom slot. A control bitlatestindicates to which pair the writer most recently wrote, and another bitindex associatedwith the pair indicates which slot of the pair was most recently written; both these controlbits are written only by the writer. The reader uses a control bitreading to indicate fromwhich pair it is reading; it sets this equal tolatest when it begins a read; conversely thewriter chooses the opposite pair when it starts a write operation.

The intuition is that the reader always reads the slot most recently completed by thewriter; the writer finishes writing the other slot of that pair (if it is operating concurrently)and subsequently moves to the other pair. The algorithm can be described as follows (ingeneric pseudocode), where we use Booleans (rather than left-right, and top-bottom) for thecontrol registers.

4

1item: TYPE

slot: ARRAY [boolean, boolean] OF item;index: ARRAY [boolean] OF boolean;latest, reading: boolean;

PROCESS writer(in: item); PROCESS reader(out: item);wpair, windex: boolean; rpair, rindex: boolean;

BEGIN BEGINwpair := !reading; rpair := latest;windex := !index[wpair]; reading := rpair;slot[wpair][windex] := in; rindex := index[rpair];index[wpair] := windex; out := slot[rpair][rindex];latest := wpair; END;

END;

It is important to recognize that the individual assignment statements from concurrentexecutions ofreader andwriter may interleave or overlap arbitrarily, so the choice ofthe exact order in which the control variables are updated in each procedure is crucial. It isalso important to recognize that the Boolean control variables, as well as the slot registersare assumed only to be safe—so that if the first statement ofreader occurs concurrentlywith the last ofwriter , then the value read fromlatest by reader may be unrelatedto that written bywriter .

2.1 Formal Specification

We will conduct our formal examination of Simpson’s algorithm using the SALenv modelchecking environment for SRI’s SAL system [BGL+00]. This is the first published investi-gation conducted using SALenv, so it is presented in tutorial detail. The SAL language andsemantics are described in its reference manual [DHOS01], but the following description isgiven in more operational terms.

The SAL notion corresponding to a process such asreader or writer is aMODULE,within which assignments to variables are described either as (variable-wise) definitions, oras guarded commands. The definitions within a module are executed atomically whereaswe need to allow the possibility that assignments by thereader are interleaved with thosefrom thewriter , so guarded commands are the appropriate construction here. Guardedcommands are given within aTRANSITION, so that a first attempt to encode thereadermight look as follows (where the guards on the guarded commands are absent for the timebeing).

5

2reader: MODULEBEGIN% variable declarations and initializations% omitted for the presentTRANSITION

[rpair’ = latest

[]reading’ = rpair

[]rindex’ = index[rpair]

[]out’ = slot[rpair][rindex]

]END;

Notice that the assignment statements are replaced by equations where the destinationvariables are primed: this is because a SAL transition specifies the relation between valuesof variables in thenew(or next) state and those in theold (or previous) state; primes indicatevalues in the new state while undecorated names refer to those in the old state. Next, observethat semicolons between assignments are replaced by the[] symbol. This indicates choiceand is needed to specify that the assignments within thereader are not performed asa single atomic step, but may be interleaved with those of thewriter . Moreover, theelements of the choice are not ordered: at any step, the system may choose any element forexecution. To force the execution to be sequential, we need to introduce aprogram counterfor the readerrpc and to rewrite the specification appropriately. Therpc variable has nospecial significance to SAL, so we must explicitly include it in guards to select the correctassignment, and must explicitly update its value after each step. This leads to the followingrevised specification.

6

reader: MODULEBEGIN% variable declarations and initializations% omitted for the presentTRANSITION

[rpc = 0 --> rpair’ = latest;

rpc’ = 1[]

rpc = 1 --> reading’ = rpair;rpc’ = 2

[]rpc = 2 --> rindex’ = index[rpair];

rpc’ = 3[]

rpc = 3 --> out’ = slot[rpair][rindex];rpc’ = 0

]END;

Theguardssuch asrpc = 2 are evaluated at each step; those that evaluate totruecause the group of assignments to the right of their arrow to be eligible for execution,and one of those eligible groups will be selected arbitrarily and executed. Notice that theassignments to the right of an arrow are grouped by means of semicolons.

Next, we need to indicate the types and status of the variables appearing in theTRAN-SITION . Variables may be declared asOUTPUT, meaning they are controlled (i.e., as-signed) by this module alone;INPUT, meaning they are observed (i.e., read) by this modulebut controlled by some other module that will be composed with it;LOCAL, meaning theyare used by this module alone; orGLOBAL, meaning they are both controlled and observedby this module and others. Here,reading is controlled byreader ; latest , slot , andindex are observed (they will be controlled by thewriter ); andrpc , out , rindex ,andrpair are local to thereader . Hence, suitable declarations for the variables appear-ing in our specification of thereader are the following (whereitem is a user-definedtype, containing the value 0, that we will consider later).

INPUTlatest: BOOLEAN,index: ARRAY BOOLEAN OF BOOLEAN,slot: ARRAY BOOLEAN OF ARRAY BOOLEAN OF item

OUTPUTreading: BOOLEAN

LOCALrpair, rindex: BOOLEAN,out: item,rpc: [0..3]

7

Notice that SAL keywords must be written in uppercase and that arrays are restricted tosingle dimension, but their elements may be arrays also.

Finally, we must initialize the local and output variables. This can involve guardedcommands or, as here, be accomplished by definitions. It is important thatrpc is initial-ized to0, but the initial values ofout , rpair , andrindex are irrelevant (because theyare assigned before they are used), so we may as well set them to0, FALSE, andFALSE,respectively. The initial value ofreading may be important, so we initialize it nondeter-ministically to eitherTRUEor FALSEusing a set assignment (the SALIN construct): theSALenv model checker will then explore all choices.

INITIALIZATIONreading IN {X: BOOLEAN | TRUE};rpair = FALSE; rindex = FALSE;out = 0;rpc = 0

We can now specify thewriter module in a similar manner. First we declare andinitialize the variables.

writer: MODULE =BEGININPUT

reading: BOOLEAN,OUTPUT

latest: BOOLEAN,index: ARRAY BOOLEAN OF BOOLEAN,slot: ARRAY BOOLEAN OF ARRAY BOOLEAN OF item

LOCALwpair, windex: BOOLEAN,wpc: [0..4]

INITIALIZATIONlatest IN {X: BOOLEAN | TRUE};wpair = FALSE; windex = FALSE;wpc = 0;(FORALL (i: BOOLEAN): index[i] IN {X: BOOLEAN | TRUE});(FORALL (x, y: BOOLEAN): slot[x][y] IN {X: item | TRUE })

Observe that the variables that were input variables for thereader are outputs for thewriter , and vice versa. Observe, also, the initialization for theindex andslot arrays:we useFORALLexpressions to iterate over the array indices, and a nondeterministic setassignment to provide the value.

The guarded commands for the writer are derived straightforwardly from the pseu-docode shown earlier. The exception is the assignment toslot whenwpc = 2. Here,we need to simulate the larger environment of thewriter that produces the values it is re-quired to write. The([] (val: item): ...) construction nondeterministically

8

selects any value from the typeitem and assigns it toval . Notice how this value is as-signed to the correct location inslot using theWITH construct; this is equivalent to theassignmentslot’[wpair][windex] = val and was chosen simply for variety.

TRANSITION[

wpc = 0 --> wpair’ = NOT reading;wpc’ = 1

[]wpc = 1 --> windex’ = NOT index[wpair];

wpc’ = 2[]

([] (val: item):wpc = 2 --> slot’ = slot WITH [wpair][windex] := val;

wpc’ = 3)[]

wpc = 3 --> index’[wpair] = windex;wpc’ = 4

[]wpc = 4 --> latest’ = wpair;

wpc’ = 0]

END;

Now that we have thereader and thewriter , we can compose them to yield thefull system. This is accomplished by the following specification. This indicates the asyn-chronous composition of the two modules; by default the inputs of one are connected to theoutputs of the other by matching the names of the variables.

system: MODULE = reader [] writer;

It might now seem that we have specified the algorithm and can proceed to examine itby model checking, but this overlooks a crucial point. Suppose the reader is at its locationrpc = 0 (where it reads the value oflatest ) while the writer is at its locationwpc= 4 (where it assigns tolatest ). We know that thewriter has not completed itswrite (because we would then havewpc = 0) but can imagine that it is somewhere in theprocess of performing it. Similarly, thereader is somewhere in the process of performingits read. Becauselatest is not assumed to be an atomic register, but merely a typesafeone, its concurrent access by thereader and thewriter can result in thereaderobtaininganyvalue. Thus, this section of the reader should be rewritten as follows.

rpc = 0 AND wpc /= 4 --> rpair’ = latest;rpc’ = 1

[]([] (arb: BOOLEAN):

rpc = 0 AND wpc = 4 --> rpair’ = arb;rpc’ = 1)

9

This specifies that ifreader accesseslatest when the writer isnotconcurrently writingit, then it obtains the value most recently written; but when the accesses are concurrent, thereader may obtain any value.

Similar constructions are required for concurrent access toindex when rpc = 2andwpc = 3 and toreading whenrpc = 1 andwpc = 0. Since each module nowrefers to the program counter and some other local variables of the other, these need to bechanged from local to input and output variables as appropriate.

2.2 Formal Examination: Mutual Exclusion

Now that we have finally completed specification of the algorithm, we can proceed to ex-amine it by model checking. The first property that we want to examine is what Simpsoncallsdata coherence: this is the requirement that thereader should not read from a slotthat thewriter is updating concurrently. Data coherence can be interpreted as mutualexclusion on slot access, and we use that term to refer to the property.

The reader is in the process of reading its slot whenrpc = 3 , and thewriter is similarly engaged whenwpc = 2; the reader accesses the slot at posi-tion [rpair][rindex] while the writer uses[wpair][windex] , so we needto be sure that wheneverwpc = 2 AND rpc = 3 then eitherwpair /= rpair orwindex /= rindex . We specify this by the following invariant.

mutex: LEMMA system |-G((wpc = 2 AND rpc = 3) =>

(wpair /= rpair OR windex /= rindex));

SALenv uses linear temporal logic (LTL) as its assertion language, where the symbolGstands for thealwaysmodality (often written2). Notice that some of the variables appear-ing in this formula are local to the modules concerned. Unfortunately, SALenv assertionscannot refer to local variables (because it is difficult to name them uniquely in complexmodule constructions), so we have to modify the specifications ofreader andwriterto make these outputs of their respective modules.

Before we can model check the specification, we need to fix theitem type. Notice thatthemutex property does not depend on the values assigned to theslot variable, so theexact range of this type is irrelevant to the property. To reduce the state space, we shouldset item to be as small as possible. A suitable definition is the following, which has justthe single value0.

item: TYPE = [0..0];

We then enclose the whole specification in aCONTEXTcalledfourslot as follows.

10

fourslot: CONTEXT =BEGIN% rest of specificationEND

The complete specification is then saved in a file calledfourslot.sal that is shown inAppendixA.

To model check themutex property, we first compile the SAL specification with thefollowing command.

sal-model-checker --output=check fourslot mutex

Here,fourslot is the name of theCONTEXT(and, by convention, of the file), andmutexis the assertion to be checked. The--output=check flag causes the output file to benamedcheck . We can then run that file with the following command.

./check --verbose

This causes SALenv to explore all possible behaviors of thesystem we have specified,and to check themutex property at every reachable state. It produces the following output.

Checking...verifiedNumber of visited states = 1248Maximum depth = 574

Because the aspects of the algorithm examined in themutex property are accuratelyrepresented in the SAL specification (e.g., no “downscaling” was necessary to make it finitestate), this output indicates formal verification of themutex property for Simpson’s algo-rithm. Because this property ensures there is no concurrent access to theslot variables,these need only have the properties of persistent registers.

2.3 Formal Examination: Freshness

Beyond the data coherence ensured by mutual exclusion, Simpson [Sim97] identifieddatafreshnessas an important requirement for his asynchronous communication mechanism.The idea is that thereader should always return the value written by the most recentactivation of thewriter .

There is a necessary delay between thewriter writing a value in a slot and it updatingthe control variables to reflect that fact. Thus, we should require only that thereaderobtain either the latest value written, or the one prior to that. To specify this, we introducetwo new output variables,current andrecent , to thewriter : current saves thevalue most recently written whilerecent saves the value before that.

11

([] (val: item):wpc = 2 --> current’ = recent;

slot’ = slot WITH [wpair][windex] := val;recent’ = val;wpc’ = 3)

In the reader , we can then specify that the value read is equal to eitherrecent orcurrent —but should it be the values of these variables now or at the point when thereader began execution? Both choices seem reasonable, so we introduce local variablesprev recent andprev current in the reader and use these to latch the values ofrecent andcurrent , respectively, as thereader starts.

rpc = 0 AND wpc /= 4 --> rpair’ = latest;prev_current’ = current;prev_recent’ = recent;rpc’ = 1


rpc = 0 AND wpc = 4 --> rpair’ = arb;prev_current’ = current;prev_recent’ = recent;rpc’ = 1)

Then, we set another local variableok to record whether the value read is equal to oneof these saved values.

rpc = 3 --> out’ = slot[rpair][rindex];ok’ = out’=recent OR out’=current

OR out’=prev_recent OR out’=prev_current;rpc’ = 0

Our requirement is thatok is alwaysTRUE.

freshness: LEMMA system |- G(ok);

We initialize current and the other similar variables to0, and we also change theinitialization of slot so that all its locations start with0, too. We must also modify thetype of item so that it has at least one value different from0.


We compile and model check the modified specification.

sal-model-checker --output=check fourslot freshness./check

12

Counter example detected:Number of visited states = 5242Maximum depth = 13----------------out = 0ok = TRUEreading = TRUE latest = TRUErindex = FALSE rpair = FALSEwpair = FALSE windex = FALSEprev_recent = 0 prev_current = 0recent = 0 current = 0wpc = 0 rpc = 0index = [true := TRUE, false := TRUE]slot = [true := [true := 0, false := 0], false := [true := 0, false := 0]]----------------Transition: <[fourslot:85]>.1wpc = 1----------------Transition: <[fourslot:92]>.1wpc = 2----------------Transition: <[fourslot:96] with [val := 1]>.1slot = [true := [true := 0, false := 0], false := [true := 0, false := 1]]current = 1wpc = 3----------------Transition: <[fourslot:102]>.1index = [true := TRUE, false := FALSE]wpc = 4----------------Transition: <[fourslot:105]>.1latest = FALSEwpc = 0----------------Transition: <[fourslot:85]>.1wpc = 1----------------Transition: <[fourslot:92]>.1windex = TRUEwpc = 2----------------Transition: <[fourslot:96] with [val := 1]>.1slot = [true := [true := 0, false := 0], false := [true := 1, false := 1]]recent = 1wpc = 3----------------Transition: <[fourslot:102]>.1index = [true := TRUE, false := TRUE]wpc = 4----------------Transition: <[fourslot:35] with [arb := TRUE]>.0prev_recent = 1prev_current = 1rpc = 1rpair = TRUE----------------Transition: <[fourslot:39]>.0rpc = 2----------------Transition: <[fourslot:42]>.0rpc = 3rindex = TRUE----------------Transition: <[fourslot:50]>.0rpc = 0ok = FALSE----------------Transition: <[fourslot:35] with [arb := FALSE]>.0out = 0ok = FALSEreading = TRUE latest = FALSErindex = TRUE rpair = FALSEwpair = FALSE windex = TRUEprev_recent = 1 prev_current = 1recent = 1 current = 1wpc = 4 rpc = 1index = [true := TRUE, false := TRUE]slot = [true := [true := 0, false := 0], false := [true := 1, false := 1]]

13

This generates a long counterexample, so we run it again using breadth-first search andcompact trace output (the flag--detailed-trace causes local variables to be printedin the trace, the--compact-trace prints onlydifferencesfrom one state to the next).

./check --bfs --verbose --detailed-trace --compact-trace

This produces a short counterexample, but it is rather difficult to explain. Disabling thenondeterministic choice atwpc = 0 produces the counterexample shown above (whichhas been edited, by combining lines, to make it fit on the page).

The behavior exposed by this counterexample is the following. All slots initially contain0; thewriter executes twice and writes1 into both left-hand (say) slots but, while it isperforming the final step of its second execution (where it assigns tolatest ), thereaderexecutes twice. Notice that the value being assigned tolatest is the same value it hasalready (indicating that thewriter has written the left-hand slots on both occasions). Thefirst execution ofreader gets the correct value oflatest (perhaps because thewriterhas not actually started to write the variable yet), but the second execution gets the wrongvalue (perhaps because thewriter is now actually in the middle of its write). This causesit to read from the right-hand slots, which have never been written by thewriter and stillcontain their initial values.

Notice that, although it was exposed by model checking a freshness property, this coun-terexample actually manifests violation of a more important property: that which Simp-son callsdata sequencing. This requires that thereader should never return dataolderthan that which it has returned previously. This property is more important than freshnessbecause it is in the nature of asynchronous operation that thereader and thewriteroperate at different speeds, so the components that receive data from thereader must beprepared to tolerate loss of some values (when thewriter is writing them faster than thereader is reading) and repetition of others (when the pace of their relative progress isreversed). What it should not expect, and may be unable to tolerate, is receiving values outof their correct temporal sequence.

The root of the problem manifested by the counterexample is that the control registersused in Simpson’s algorithm are not atomic, merely safe. This means that they can returnanyvalue when read and written concurrently, and this is what causes the algorithm to fail.Notice, however, that the counterexample manifested the problem when thesamevalue waswritten to a control register as it had already. Surely such a write is unnecessary, and if itwere not performed, this particular problem could not arise: there would be no concurrentread and write (since there would be no write), and the reader would get the correct value(since the control register already had the value required). But what if the control registerdoesnot already contain the desired value? The write must then take place and surely thisprovokes the same problem of concurrent reads and writes to a nonatomic register. The vitalinsight that vitiates this concern is that if a safeBooleanregister is written only when thenew value isdifferentfrom the old, then it behaves as an atomic register.1 The value before

1We will later see that this insight is incorrect.

14

the write may beTRUE(say), so that afterward it will beFALSE; a concurrent read canproduce any value, but there are only two choices for a Boolean register—hence, the valueobtained must be consistent with the read occurring either atomically before the write, oratomically afterward.

Simpson possessed this insight and states [Sim90, Page 20, Section 2.3]

“The co-operative access control technique is only sound if we can rely com-pletely on the integrity of the control variables.

. . .

“Fortunately, there is a variable type whose value is always guaranteed to becoherent, and where reading and writing operations can be concurrent andneed not interfere with each other; this is the bit variable.

. . .

“The integrity of any fully asynchronous mechanisms rests ultimately on thisproperty of the bit variable. Practical implementations of such variables,when used for control within an asynchronous mechanism, must ensure thefollowing:

. . .

“(b) A write operation which does not change the value must not induce anydisturbance which might cause a concurrent read to obtain an incorrectvalue.”

The simplest way to ensure the absence of “any disturbance” with a “write operation whichdoes not change the value” is to eschew such writes: simply modify the algorithm so thatBoolean control variables are written only if they change the value of the register. Ourhope is that this modification corrects the problem identified by the counterexample. Themodified algorithm is shown below.

15

3item: TYPE

slot: ARRAY [boolean, boolean] OF item;index: ARRAY [boolean] OF boolean;latest, reading: boolean;

PROCESS writer(in: item);wpair, windex: boolean;

BEGINwpair := !reading;windex := !index[wpair];slot[wpair][windex] := in;index[wpair] := windex;IF latest /= wpair THEN latest := wpair ENDIF;

END;

PROCESS reader(out: item);rpair, rindex: boolean;

BEGINrpair := latest;IF reading /= rpair THEN reading := rpair ENDIF;rindex := index[rpair];out := slot[rpair][rindex];

END;

Notice that the assignmentindex[wpair] := windex in the fourth line of thewriter does not require theIF...THEN ... protection because these variables arewritten only by thewriter , and windex is earlier assigned to the negation ofin-dex[wpair] . We examine this modified algorithm in the following section.

2.4 Formal Examination: The Modified Specification

The SAL specification can be adjusted to correspond to the corrected presentation of thealgorithm given in 3 . For example, theTRANSITION for the reader is shown below(assignments to the verification variables such asrecent , prev current have beenomitted). The full specification is given in AppendixB.

16

TRANSITION[

rpc = 0 AND wpc /= 4 -->rpair’ = latest;rpc’ = IF reading = rpair’ THEN 2 ELSE 1 ENDIF


rpc = 0 AND wpc = 4 -->rpair’ = arb;rpc’ = IF reading = rpair’ THEN 2 ELSE 1 ENDIF)

[]rpc = 1 --> reading’ = rpair;

rpc’ = 2[]

rpc = 2 AND (wpc /= 3 OR rpair /= wpair) -->rindex’ = index[rpair];rpc’ = 3


rpc = 2 AND wpc = 3 AND rpair = wpair -->rindex’ = arb;rpc’ = 3)

[]rpc = 3 --> out’ = slot[rpair][rindex];

rpc’ = 0]

END;

If we model check the revised specification with SALenv, it again reports failure. Ex-amination of the counterexample reveals that it indicates a weakness in our specification offreshness, rather than a true flaw in the algorithm. The problem is that a single activationof the reader can be concurrent with multiple activations of thewriter , and the inter-leaving can be such that the value obtained by thereader is one that was written in themiddle of the series of writes—whereas our verification variables (as used in the testok )capture only those written at the beginning or end. Since there can be any number of writesoverlapping a read, it looks as if we need an unbounded number of verification variables tocapture these legitimate outputs by thereader . We could bound the number by limitingthe number of overlapping writes, or by putting a bound on the model checker search depth,but these solutions seem ad hoc. Furthermore, freshness is merely a desirable property; asexplained earlier, the property that is really essential is data sequencing.

A very good way to examine this property is to cause thewriter to write consecutiveintegers and then require that the reader return nondecreasing values.2 To specify this, we

2This idea is due to N. Shankar.

17

first increase the range of the typeitem so that it will permit an interesting number ofdifferent values to be written.


Then we modify the selection of values written by thewriter so that they becomestrictly increasing. This can be done as follows (where the local variableprev is used toremember the previous value and is initialized to0).

([] (val: item):wpc = 2 AND val > prev -->

slot’ = slot WITH [wpair][windex] := val;prev’ = val;wpc’ = 3)

Finally, we specify that the values obtained by thereader must be nondecreasing.

atomic: LEMMA system |- G(out’ >= out);

The expression specifies that the value ofout after the assignments in any command mustbe no less than its value before. This property is a manifestation of that called “atomicity”in the computer science literature, hence the name used in the specification. (Atomicity isthe property that any sequence of concurrent reads and writes behaves as if each had beenperformed indivisibly, and all had been performed in some definite sequence.)

The state space of this model is larger than previously, so we turn on some optimiza-tions.

sal-model-checker --output=check --optimize fourslotmodified atomic./check --bfs --verbose --detailed-trace --compact-trace

To our astonishment, this exercise returns a counterexample.The essence of the counterexample is as follows. Thewriter starts writing in (say)

the top left-hand slot. Thereader starts while thewriter is at wpc = 3 (i.e., in theprocess of changingindex[rpair] so that the left index indicates the top slot ratherthan the bottom). Because this is merely a safe register, thereader may obtain any valuefor index[rpair] (at rpc = 2 ), and it obtains the new value (i.e., top) and so returnsthe value most recently written by thewriter . Immediately following the completion ofthis activation of thereader , a new one begins (thewriter remains atwpc = 3). Atrpc = 2 , this activation obtains the old value forindex[rpair] and so returns thevalue from the slotpreviousto the one most recently written, thereby violating the datasequencing requirement.

Whether this is a real bug or not depends on the assumptions from which one approachesthe problem. From the computer science perspective, in which the problem is formulated asthat of constructing an atomic register from merely safe registers, it is a genuine bug. Thesource of the bug is the observation on Page14:

18

“The vital insight that vitiates this concern is that if a safeBooleanregister iswritten only when the new value isdifferent from the old, then it behavesas an atomic register.

This insight is incorrect: it is true that a concurrent read of a safe Boolean register thatis written only when its new value is different from its old must always return the old or thenew value, but asecondconcurrent read may produce theold value when the first producedthenewvalue. This is not the behavior of an atomic register—it is the behavior of merely aregular register.

Simpson’s algorithm depends on atomicity of its Boolean control registers. As we haveseen, the construction suggested by Simpson (writing the control variables only when theirnew value is different from their old value) is inadequate to achieve this requirement, givenonly safe control registers. However, Simpson does not claim that his algorithm assumesonly that the control registers are safe. Rather, he assumes them to be atomic and hisdiscussion in [Sim90, Page 20, Section 2.3] (from which comes the construction that controlvariables should be written only when their new value is different from their old value) canbe seen as suggestions to an implementor, rather than a complete algorithm.

Thus, to be accurate to Simpson’s intent, we should examine correctness of his al-gorithm when the control registers are assumed to be atomic. This is undertaken in thefollowing section.

2.5 Formal Examination: Assuming Atomic Control Registers

If atomic control registers are assumed, we could revert to the original specification2 fromPage6. It seems useful, however, to include at least the detail that the control registers arewritten only when their value will be changed. TheTRANSITION for the reader thenappears as follows. Notice that we have eliminated all the([] (arb: BOOLEAN):...) constructions, since these are needed only to model safe registers. The full specifi-cation is given in AppendixC.

19

TRANSITION[

rpc = 0 --> rpair’ = latest;rpc’ = 1

[]rpc = 1 AND reading /= rpair --> reading’ = rpair;

rpc’ = 2[]

rpc = 1 AND reading = rpair -->rpc’ = 2

[]rpc = 2 --> rindex’ = index[rpair];

rpc’ = 3[]


]END;

We can model check theatomic property for this specification with the followingcommands (the Unixtime command measures the CPU time used).

sal-model-checker --output=check --optimize fourslotatomic atomictime ./check --bfs --verbose

The following results are produced.

Checking.............................................verifiedNumber of visited states = 427378Maximum depth = 4287.770u 0.410s 1:28.91 99.1% 0+0k 0+0io 605pf+0w

The timing data indicates that model checking used just over 87 seconds (on an 800 MHzPentium III running Red Hat Linux V7.1) to examine 427,378 states. The atomicity prop-erty is verified for this version of the specification.

20

Chapter 3

Conclusion

We have examined Simpson’s four-slot fully asynchronous communication mechanism[Sim90] by model checking with SALenv. Simpson’s mechanism can be seen as an al-gorithm for constructing a lock-free and wait-free atomic register from registers satisfyingweaker assumptions. Atomic registers are crucial for reliable communication of data be-tween separately clocked components.

We showed that Simpson’s algorithm ensures mutual exclusion (i.e., the reader andwriter never access the same data slot concurrently), and hence coherence or integrity ofthe data, when its registers satisfy the weakest of all assumptions: those of merely saferegisters.

However, we found that the algorithm ensures atomicity (i.e., the property that the val-ues read are as if reads and writes do not overlap), and hence correct data sequencing, onlywhen its control registers are already atomic. We also found that modifying the algorithmso that the Boolean control registers are written only when their values will be changed isinadequate to overcome this limitation.

It seems unsatisfactory to base a construction for atomic registers on the assumption thatits control registers are already atomic. It may be that this assumption can be dischargedwith careful electrical design (particularly for the modified algorithm, where the circum-stances in which it fails may be considered to require rare electrical events). Nonetheless, itwould seem preferable to use a construction that truly requires merely safe control registers.The algorithm of Anderson and Gouda [AG92] may satisfy this requirement.

Our formal examination used model checking (actually, explicit-state reachability anal-ysis). For the mutual exclusion property, our modeling was exact and therefore provides trueverification of this property. For atomicity, our modeling is indirect. We identify atomicitywith the requirement that writes of strictly increasing integer values should lead to readswhose values are nondecreasing. This requirement is certainly necessary for atomicity, butmay not be sufficient. However, Hesselink [Hes02], identifies a criterion for atomicity thatexplicitly associates sequence numbers with values written and read; we can regard the in-tegers used in our experiments as being their own sequence numbers. Thus, although we

21

lack a proof, it seems very plausible that our requirement is sufficient as well as necessary.Our model checking is compromised in that we consider sequences of no more than eightwrites, but intuitively this seems sufficient to explore all behaviors (the counterexamplesthat exposed flawed assumptions were all found using only two values). Thus, we considerour model checking of the atomicity property to provide very strong, but not conclusive,evidence for correctness of Simpson’s algorithm with atomic control registers.

Clark [Cla00] has examined several atomic register constructions, including Simpson’s,using Petri nets. His Petri net models are much further removed from the natural presen-tation of the algorithms than our SALenv specifications, and the required properties arealso stated indirectly. Clark’s treatment of data freshness and sequencing derive from the“role models” of Simpson [Sim97], which are themselves abstracted descriptions that arenot fully independent of the algorithms under examination. Clark assumes atomic controlvariables and verifies the properties of data coherence (mutual exclusion), freshness, and se-quencing. He also considers a certain model of metastability that can be seen as weakeningthe assumption of atomicity on the control variables, and shows that Simpson’s algorithmfails in this case. Clark’s work (which was not known to the author when this work wasperformed) is similar to that reported here, but our examination of atomicity assumptionson the control registers is more comprehensive, and we also consider our modeling in SALto be much more direct and accessible than that using Petri nets.

Henderson and Paynter [HP02] have formally verified the mutual exclusion property ofSimpson’s algorithm using theorem proving in PVS, but they have not yet examined theatomicity property. Hesselink [Hes02] has formally verified some multi-reader atomic reg-ister constructions (that build on single-reader constructions of the kind considered here)using theorem proving in ACL2. Both theorem proving approaches are substantially morecomplex than ours. As noted above, model checking is exact for the mutual exclusion prop-erty and it is plausibly so for the atomicity property, so theorem proving provides additionalbenefit only for the latter property, and at rather large cost. It would be interesting to see iftheorem proving can be used to justify the approximation used in model checking the atom-icity property; if it can, this combination of theorem proving and model checking mightprovide the most cost-effective approach to formal verification for this class of algorithms.

We have seen that Simpson’s algorithm can fail if its control registers are not atomic.Although it includes suggestions for realizing atomic Boolean control registers, Simpson’spaper does not provide an algorithm for realizing them, and the suggestion that the controlregisters are written only when their value will be changed reduces but does not eliminatethe failure mode. Unless a verifiable construction for realizing Boolean control registers isemployed, Simpson’s algorithm cannot be considered verifiably correct. It requires exper-tise in the application domain (to determine the consequences of possible loss of atomicity),in circuit design (to determine the plausibility of the circumstances that lead to its failure),and in safety analysis to decide whether the algorithm is fit for deployment in a particularsafety-critical context.

22

Because Simpson’s algorithm is not unconditionally correct, it seems desirable to ex-amine other atomic register constructions that share its good features (it is short and usesfew control registers) and may remove its limitations. The algorithm of Anderson andGouda [AG92] seems promising and it would be interesting to subject it to examinationsimilar to that performed here. Clark’s analysis [Cla00] found no flaws in this algorithm,but our examination of the version given by Clark [Cla00, Figure 5.19] finds that it failseven themutex property when the control variables are merely safe.

23

Bibliography

[AG92] J. H. Anderson and M. G. Gouda. A criteron for atomicity.Formal Aspects ofComputing, 4:273–298, 1992.21, 23

[And01] James H. Anderson. Lamport on mutual exclusion: 27 years of planting seeds.In 20th ACM Symposium on Principles of Distributed Computing, pages 3–12,Newport, RI, August 2001. Association for Computing Machinery.2

[BGL+00] Saddek Bensalem, Vijay Ganesh, Yassine Lakhnech, Cesar Munoz, Sam Owre,Harald Rueß, John Rushby, Vlad Rusu, Hassen Saıdi, N. Shankar, Eli Singer-man, and Ashish Tiwari. An overview of SAL. In C. Michael Holloway, editor,LFM 2000: Fifth NASA Langley Formal Methods Workshop, pages 187–196,Hampton, VA, June 2000. NASA Langley Research Center. Proceedings avail-able athttp://shemesh.larc.nasa.gov/fm/Lfm2000/Proc/ . 5

[BP87] James E. Burns and Gary L. Peterson. Constructing multi-reader atomic val-ues from non-atomic values. In6th ACM Symposium on Principles of Dis-tributed Computing, pages 222–231, Vancouver, British Columbia, Canada,August 1987. Association for Computing Machinery.2

[CB97] Jing Chen and Alan Burns. A three-slot asynchronous reader-writer mechanismfor multiprocessor real-time systems. Technical Report YCS-286, Departmentof Computer Science, University of York, May 1997.4

[Cla00] Ian G. Clark. A Unified Approach to the Study of Asynchronous Communica-tion Mechanisms in Real Time Systems. PhD thesis, King’s College, LondonUniversity, May 2000.2, 22, 23

[DHOS01] David Dill, Thomas Henzinger, Sam Owre, and N. Shankar. The SAL lan-guage. Technical Report SRI-CSL-01-02, Computer Science Laboratory, SRIInternational, Menlo Park, CA, March 2001.5

[Hes02] Wim H. Hesselink. An assertional criterion for atomicity.Acta Informatica,28(5):343–366, 2002.21, 22

25

http://shemesh.larc.nasa.gov/fm/Lfm2000/Proc/

[HP02] N. Henderson and S. E. Paynter. The formal classification and verification ofSimpson’s 4-slot asynchronous communication mechanism. In Peter Lindsay,editor,Formal Methods Europe (FME’02), Lecture Notes in Computer Science,Copenhagen, Denmark, July 2002. Springer-Verlag. To appear.2, 3, 22

[HV92] S. Haldar and K. Vidyasankar. Counterexamples to a one writer multireaderatomic variable construction of Burns and Peterson.ACM Operating SystemsReview, 26(1):78–87, January 1992.2

[KG94] Hermann Kopetz and Gunter Grunsteidl. TTP—a protocol for fault-tolerantreal-time systems.IEEE Computer, 27(1):14–23, January 1994.2

[Kop99] Hermann Kopetz. Elementary versus composite interfaces in distributed real-time systems. InThe Fourth International Symposium on Autonomous Decen-tralized Systems, Tokyo, Japan, March 1999. IEEE Computer Society.1

[KR93] Hermann Kopetz and Johannes Reisinger. The non-blocking write protocolNBW: A solution to a real-time synchronization problem. InReal Time Sys-tems Symposium, pages 131–137, Raleigh-Durham, NC, December 1993. IEEEComputer Society.2

[Lam77] Leslie Lamport. Concurrent reading and writing.Association for ComputingMachinery, 20(11):806–811, November 1977.1, 2

[Lam86] Leslie Lamport. On interprocess communication—Part I: Basic formalism, PartII: Algorithms. Distributed Computing, 1(2):77–101, 1986.2, 3

[Pet87] Gary Peterson. Concurrent reading while writing.ACM Transactions on Pro-gramming Languages and Systems, 5(1):46–55, 1987.2

[Rus02] John Rushby. An overview of formal verification for the time-triggered archi-tecture. In Werner Damm and Ernst-Rudiger Olderog, editors,Formal Tech-niques in Real-Time and Fault-Tolerant Systems, Lecture Notes in ComputerScience, Oldenburg, Germany, November 2002. Springer-Verlag. To appear.1

[Sim90] H. R. Simpson. Four-slot fully asynchronous communication mechanism.IEEProceedings, Part E: Computers and Digital Techniques, 137(1):17–30, Jan-uary 1990. 2, 4, 15, 19, 21

[Sim97] H. R. Simpson. Role model analysis of an asynchronous communicationmechanism. IEE Proceedings, Part E: Computers and Digital Techniques,144(4):232–240, July 1997.11, 22

26

[Tro89] John Tromp. How to construct an atomic variable. InDistributed Algorithms(3rd International Workshop WDAG ’89), volume 392 ofLecture Notes in Com-puter Science, pages 292–302, Nice, France, September 1989. Springer-Verlag.2

[TTT01] Time-Triggered Technology TTTech Computertechnik AG, Vienna, Austria.Specification of the TTP/C Protocol (version 0.6p0504), May 2001. 2

27

Appendix A

Simpson’s Algorithm in SAL

The following presents Simpson’s algorithm, modeled in the SAL specification language.The modeling of control variables reproduces the behavior of safe registers. Themutexproperty is verified for this specification, but thefreshness property fails.

fourslot: CONTEXT =BEGINitem: TYPE = [0..0];

reader: MODULE =BEGININPUT

latest: BOOLEAN,index: ARRAY BOOLEAN OF BOOLEAN,slot: ARRAY BOOLEAN OF ARRAY BOOLEAN OF item,recent, current: BOOLEAN,wpair: BOOLEAN,wpc: [0..4]

OUTPUTreading: BOOLEAN,rpair, rindex: BOOLEAN,ok: BOOLEAN,rpc: [0..3]

LOCALprev_recent, prev_current: item,out: item

INITIALIZATIONreading IN X: BOOLEAN | TRUE;rpair = FALSE; rindex = FALSE;ok = TRUE;prev_recent = 0; prev_current = 0;out = 0;rpc =0

29

TRANSITION[

rpc = 0 AND wpc /= 4 --> rpair’ = latest;prev_current’ = current; prev_recent’ = recent;rpc’ = 1

[]([] (arb: BOOLEAN):rpc = 0 AND wpc = 4 --> rpair’ = arb;

prev_current’ = current; prev_recent’ = recent;rpc’ = 1)

[]rpc = 1 --> reading’ = rpair;

rpc’ = 2[]

rpc = 2 AND (wpc /= 3 OR rpair /= wpair) -->rindex’ = index[rpair];rpc’ = 3

[]([] (arb: BOOLEAN):rpc = 2 AND wpc = 3 AND rpair = wpair --> rindex’ = arb;

prev_current’ = current; prev_recent’ = recent;rpc’ = 3)


ok’ = out’=recent OR out’=currentOR out’=prev_recent OR out’=prev_current;

rpc’ = 0]

END;


reading: BOOLEAN,rpc: [0..3]

OUTPUTlatest: BOOLEAN,index: ARRAY BOOLEAN OF BOOLEAN,slot: ARRAY BOOLEAN OF ARRAY BOOLEAN OF item,wpair, windex: BOOLEAN,recent, current: item,wpc: [0..4]

INITIALIZATIONlatest IN X: BOOLEAN | TRUE;wpair = FALSE; windex = FALSE;wpc = 0;

30

(FORALL (i: BOOLEAN): index[i] IN X: BOOLEAN | TRUE);recent = 0; current = 0;(FORALL (x, y: BOOLEAN): slot[x][y] = 0)

TRANSITION[

wpc = 0 AND rpc /= 1 --> wpair’ = NOT reading;wpc’ = 1

[]([](arb:BOOLEAN):

wpc = 0 AND rpc = 1 --> wpair’ = NOT reading;wpc’ = 1)


wpc’ = 2[]

([] (val: item):wpc = 2 --> recent’ = current;

slot’ = slot WITH [wpair][windex] := val;current’ = val;wpc’ = 3)

[]wpc = 3 --> index’[wpair] = windex;

wpc’ = 4[]

wpc = 4 --> latest’ = wpair;wpc’ = 0

]END;


mutex: LEMMA system |-G((wpc = 2 AND rpc = 3) => (wpair /= rpair OR windex /= rindex));

freshness: LEMMA system |- G(ok);

END

31

Appendix B

Modified Simpson’s Algorithm inSAL

The following presents Simpson’s algorithm, modified so that control registers are writtenonly when the write will change the stored value. Control variables are modeled as saferegisters. Theatomic property fails for this specification.



latest: BOOLEAN,index: ARRAY BOOLEAN OF BOOLEAN,slot: ARRAY BOOLEAN OF ARRAY BOOLEAN OF item,wpair: BOOLEAN,wpc: [0..4]

OUTPUTreading: BOOLEAN,rpair, rindex: BOOLEAN,rpc: [0..3],out: item

INITIALIZATIONreading IN X: BOOLEAN | TRUE;rpair = FALSE; rindex = FALSE;out = 0;rpc =0

TRANSITION[

rpc = 0 AND wpc /= 4 --> rpair’ = latest;

33

rpc’ = IF reading = rpair’ THEN 2 ELSE 1 ENDIF[]

([] (arb: BOOLEAN):rpc = 0 AND wpc = 4 --> rpair’ = arb;

rpc’ = IF reading = rpair’ THEN 2 ELSE 1 ENDIF)[]

rpc = 1 --> reading’ = rpair;rpc’ = 2

[]rpc = 2 AND (wpc /= 3 OR rpair /= wpair) --

> rindex’ = index[rpair];rpc’ = 3

[]([] (arb: BOOLEAN):rpc = 2 AND wpc = 3 AND rpair = wpair --> rindex’ = arb;

rpc’ = 3)[]


]END;



OUTPUTlatest: BOOLEAN,index: ARRAY BOOLEAN OF BOOLEAN,slot: ARRAY BOOLEAN OF ARRAY BOOLEAN OF item,wpair, windex: BOOLEAN,wpc: [0..4]

LOCALprev: item

INITIALIZATIONlatest IN X: BOOLEAN | TRUE;wpair = FALSE; windex = FALSE;prev = 0;wpc = 0;(FORALL (i: BOOLEAN): index[i] IN X: BOOLEAN | TRUE);(FORALL (x, y: BOOLEAN): slot[x][y] = 0)

TRANSITION[

wpc = 0 AND rpc /= 1 --> wpair’ = NOT reading;wpc’ = 1

34

[]([](arb:BOOLEAN):

wpc = 0 AND rpc = 1 --> wpair’ = arb;wpc’ = 1)


wpc’ = 2[]

([] (val: item):wpc = 2 AND val > prev --> slot’ = slot WITH [wpair][windex] := val;

prev’ = val;wpc’ = 3)


wpc’ = IF latest = wpair THEN 0 ELSE 4 ENDIF[]

wpc = 4 --> latest’ = wpair;wpc’ = 0

]END;




END

35

Appendix C

Simpson’s Algorithm with AtomicControl Registers in SAL

The following presents Simpson’s algorithm, modified so that control registers are writtenonly when the write will change the stored value. Control variables are modeled as atomicregisters. Theatomic property is verified for this specification.



latest: BOOLEAN,index: ARRAY BOOLEAN OF BOOLEAN,slot: ARRAY BOOLEAN OF ARRAY BOOLEAN OF item,wpair: BOOLEAN,wpc: [0..4]

OUTPUTreading: BOOLEAN,rpair, rindex: BOOLEAN,rpc: [0..3],out: item

INITIALIZATIONreading IN X: BOOLEAN | TRUE;rpair = FALSE; rindex = FALSE;out = 0;rpc =0

TRANSITION[

rpc = 0 --> rpair’ = latest;

37

rpc’ = 1[]

rpc = 1 AND reading /= rpair --> reading’ = rpair;rpc’ = 2

[]rpc = 1 AND reading = rpair -->

rpc’ = 2[]

rpc = 2 --> rindex’ = index[rpair];rpc’ = 3


rpc’ = 0]

END;



OUTPUTlatest: BOOLEAN,index: ARRAY BOOLEAN OF BOOLEAN,slot: ARRAY BOOLEAN OF ARRAY BOOLEAN OF item,wpair, windex: BOOLEAN,wpc: [0..4]

LOCALprev: item

INITIALIZATIONlatest IN X: BOOLEAN | TRUE;wpair = FALSE; windex = FALSE;prev = 0;wpc = 0;(FORALL (i: BOOLEAN): index[i] IN X: BOOLEAN | TRUE);(FORALL (x, y: BOOLEAN): slot[x][y] = 0)

TRANSITION[

wpc = 0 --> wpair’ = NOT reading;wpc’ = 1


wpc’ = 2[]

([] (val: item):wpc = 2 AND val>prev --> slot’ = slot WITH [wpair][windex] := val;

38

prev’ = val;wpc’ = 3)


wpc’ = 4[]

wpc = 4 AND latest /= wpair --> latest’ = wpair;wpc’ = 0

[]wpc = 4 AND latest = wpair -->

wpc’ = 0]

END;




END

39

model checking simpson’s four-slot fully asynchronous

Documents