A SIMPLE APPROACH TO SPECIFYING CONCURRENT SYSTEMS

Transcription

1 Artificia Inteigence and Language Processing ]acques Cohen Editor A SIMPLE APPROACH TO SPECIFYING CONCURRENT SYSTEMS LESLIE LAMPORT Over the past few years, I have deveoped an approach to the forma specification of concurrent systems that I now ca the transition axiom method. The basic formaism has aready been described in [12] and [], but the forma detais tend to obscure the important concepts. Here, I attempt to expain these concepts without discussing the detais of the underying formaism. Conc:urrent systems are not easy to specify. Even a simpe system can be subte, and it is often hard to find thee appropriate abstractions that make it understandabe. Specifying a compex system is a formidabe engineering task. We can understand compex structures ony if they are composed of simpe parts, so a method for specifying compex systems must have a simpe conceptua basis. I wi try to demonstrate that the tra:nsition axiom method provides such a basis. However, I wi not address the engineering probems associated with specifying rea systems. Instead, the concepts wi be iustrated with a series of toy exampes th,at are not meant to be taken seriousy as rea specifications. Are you proposing a specification anguage? No. The transition axiom method provides a conceptua and ogica foundation for writing forma specifications; it is not a specification anguage. The method determines,what a specification must say; a anguage determines in detai how it is said. What do you mean by a forma specification? I find it hepfu to view a specification as a contract between the user of a system and its impementer. The contract shoud te the user everything he must know to use the system, and it shoud te the impementer everything he must know about the system to impement it. In principe, once this contract has been agreed upon, t.he user and the impementer have no need for further communication. (This view describes the function of the specification; it is not meant as a paradigm for how systems shoud be buit.) ACM /89/ $1.50 For a specification to be forma, the questio:n of whether an impementation satisfies the specification must be reducibe to the question of whether an assertion is provabe in some mathematica system. To demonstrate that he has met the terms of the contract, the impementer shoud resort to ogic rather than contract aw. This does not mean that an impementation must be accompanied by a mathematica proof. It does mean that it shoud be possibe, in principe though not necessariy in practice, to provide such a proof for a correct impementation. The existence of a forma basis for the specification method is the ony way I know to guarantee that specifications are unambiguous. Utimatey, the systems we specify are physica objects, and mathematics cannot prove physica properties. We can prove properties ony of a mathe:matica mode of the system; whether or not the system correcty impements the mode must remain a question of aw and not of mathematics. Just what is a system? By system, I mean anything that interacts with its environment in a discrete (digita) fashion across a we-defined boundary. An airine reservation system is such a system, where the boundary might be drawn between the agents using the system, who are part of the environment, and the terminas, which are part of the system. A Pasca procedure is a system w:hose environment is the rest of the program, with which it interacts by responding to procedure cas and accmessing goba variabes. Thus, the system being specified may be just one component of a arger system. The soar system is not a system in this sense, both because it is not discrete and because there is no wedefined notion of an environment with which it interacts. A rea system has many properties, ranging from its response time to the coor of the cabinet. No forma method can specify a of these properties. Which ones ca be specified with the transition axiom method? 32 Communications of the ACM January 1989 Voume 32 Number I

2 The transition axiom method specifies the behavior of a system-that is, the sequence of observabe actions it performs when interacting with the environment. More precisey, it specifies two casses of behaviora properties: safety and iveness properties. Safety properties assert what the system is aowed to do, or equivaenty, what it may not do. Partia correctness is an exampe of a safety property, asserting that a program may not generate an incorrect answer. Liveness properties assert what the system must do. Termination is an exampe of a iveness property, asserting that a program must eventuay generate an answer. (Apern and Schneider [2] have formay defined these two casses of properties.) In the transition axiom method, safety and iveness properties are specified separatey. There are important behaviora properties that cannot be specified by the transition axiom method; these incude average response time and probabiity of faiure. A transition axiom specification can provide a forma mode with which to anayze such properties, but it cannot formay specify them. There are aso important nonbehaviora properties of systems that one might want to specify, such as storage requirements and the coor of the cabinet. These ie competey outside the ream of the method. Why specify safety and iveness properties separatey? There is a singe formaism that underies a transition axiom specification, so there is no forma separation between the specification of safety and iveness properties. However, experience indicates that different methods are used to reason about the two kinds of properties and it is convenient in practice to separate them. I consider the abiity to decompose a specification into iveness and safety properties to be one of the advantages of the method. (One must prove safety properties in order to verify iveness properties, but this is a process of decomposing the proof into smaer emmas.) Can the method specify rea-time behavior? Worst-case behavior can be specified, since the requirement that the system must respond within a certain ength of time can be expressed as a safety propertynamey, that the cock is not aowed to reach a certain vaue without the system having responded. Average response time cannot be expressed as a safety or iveness property. The transition axiom method can assert that some action either must occur (iveness) or must not occur (safety). Can it aso assert that it is possibe for the action to occur? No. A specification serves as a contractua constraint on the behavior of the system. An assertion that the system may or may not do something provides no constraint and therefore serves no function as part of the forma specification. Specification methods that incude such assertions generay use them as poor substitutes for iveness properties. Some methods cannot specify that a certain input must resut in a certain response, See [ZO] for an exampe of faiure anaysis appied to a specification. specifying instead that it is possibe for the input to be foowed by the response. Every specification I have encountered that used such assertions was improved by repacing the possibiity assertions with iveness properties that more accuratey expressed the system s informa requirements. Imprecise wording can make it appear that a specification contains a possibiity assertion when it reay doesn t. For exampe, one sometimes states that it must be possibe for a transmission ine to ose messages. However, the specification does not require that the oss of messages be possibe, since this woud prohibit an impementation that guaranteed no messages were ost. The specification might require that something happens (a iveness property) or doesn t happen (a safety property) despite the oss of messages. Or, the statement that messages may be ost might simpy be a comment about the specification, observing that it does not require that a messages be deivered, and not part of the actua specification. f a safety property asserts that some action cannot happen, doesn t its negation assert that the action is possibe? In a forma system, one must distinguish the ogica formua A from the assertion - A, which means that A is provabe in the ogic; - A is not a formua of the ogic itsef. In the ogic underying the transition axiom method, if A represents a safety property asserting that some action is impossibe, then the negation of A, which is the formua 7A, asserts that the action must occur. The action s possibiity is expressed by the negation of - A, which is a metaformua and not a formua within the ogic. See [o] for more detais. SAFETY PROPERTIES A Soda Machine We begin with a system consisting of a soda machine, in which the user deposits either a haf doar or two quarters and the machine in return dispenses a can of soda. Figure 1, together with the initia condition that the machine starts in state I, provides a simpe specification of the safety properties of this machine. Figure 1 specifies that, when the machine is in state I, either a deposit quarter action can occur that takes the machine to state II or a deposit haf doar action can occur that takes it to state III. From state II, ony a deposit quarter action taking the machine to state III can occur. From state III, ony a dispense soda action taking the machine to state I can occur. This is a safety specification, so it asserts that these are the ony actions that are aowed to occur; it does not assert that any actions must occur. What happens if the user deposits first a quarter then a haf doar? The specification disaows this behavior. (Remember that the exampes are not supposed to be reaistic speci- For the reader unfamiiar with cooquia American Engish and United States currency: soda is a carbonated soft drink, a quarter is a coin worth $0.25. and a hnfdoar coin is worth $0.50. January 1989 Voume 32 Number 1 Communications of the ACM 33

3 dispense soda I -II-III quarter quarter deposit haf doar FIGURE 1. Specification of a Soda Machine fications.) There are two ways to view this aspect of the specification: The specification constrains the behavior of the u:ser, forbidding him to deposit a haf doar after he h(as deposited a quarter. The specification does not state what the soda machine is supposed to do if the user deposits a quarter then a haf doar; the impementer is free to buid the machine so it does anything he wants if the user exhibits this kind of incorrect behavior. Which view we take makes no difference to how we write and reason about specifications. Figure 1 is supposed to specify the soda machine s behavior; why does it aso specify the user s behavior? It is impossibe to impement a system that functions propery in the presence of arbitrary behavior by the environment. A more reaistic specification woud aow the user to deposit an arbitrary sequence of coins, perhaps returning them if an inappropriate sequence had been deposited; it woud not aow the user to attack the machine with a sedgehammer. (We sha see ater how the sedgehammer is disaowed.) The specification of a program procedure usuay incudes a precondition that constrains the environment by forbidding cas whose arguments do not satisfy the precondition; the specification of a circuit incudes timing constraints that restrict when the environment can change the input eves [16]. Figure 1 is a simpe state-transition diagram. Such diagrams work we for vey simpe exampes, but don t they become too compicated when specifying rea systems? Yes; these diagrams do not scae we to arger prob- ems. State-transition diagrams represent just one particuar anguage that can be used with the transition axiom method. The shortcomings of these diagrams are imitations of the anguage, not of the transition axiom method. Other anguages are needed for writing transition axiom specifications of arger systems; I: wi have more to say about anguages ater. What is the fundamenta, anguage-independent concept that is expressed by the state-transition diagram of Figure I? Aowed state transitions. In the transition axiom method, one specifies safety properties by describing a set of states and a transitions between states that are aowed to occur. There are many different anguages with which one can describe states and transitions. The concept of state transitions, as iustrated b,y the diagram of Figure 1, has been used for years. Is there anything different about the transition axiom method? What is new in the transition axiom method is not the diagram, but its interpretation as a forma specification. This new interpretation is needed because conventiona state-transition methods do not adequatey address the fundamenta question of what it means for an impementation to meet such a specification One of the advantages of the transition axiom method is that specifications of safety properties can be written in friendy, famiiar notations such as state-transition diagrams. The specifications ook od; the meaning we assign to them is new.3 What is different about the interpretation of Figure 1 in the transition axiom method? The naive interpretation of Figure 1 is that it specifies a More precisey. I beieve that this meaning was new when it was proposed in [12] and [13]: it has since appeared in [9] and esewhere. 34 Communications of the ACM January 1989 Voume 32 Number 1

4 three-state machine. In more sophisticated approaches, such as the one described by Jones [a], the diagram is interpreted to mean that there exists some state function, et s ca it f, that assumes the vaues I, II, and III; the diagram specifies how f can change. More precisey, the soda machine is assumed to have some unspecified set of states, et s ca it S; the machine s behavior is described by the sequence of states so, s, sz,... it passes through. The state function f is a mapping from S to the set of vaues {I, II, III). The diagram of Figure 1 specifies that for each state transition si + s;+~ in this sequence, the change of vaue from f(si) to f(si+) is one of the foowing: f(si) = I, f(si+) = II, and the change is caused by a deposit quarter action. f(si) = I, f(si+) = III, and the change is caused by a deposit haf doar action. f(s;) = II, f(si+i) = III, and the change is caused by a deposit quarter action. f(si) = III, f(si+) = I, and the change is caused by a dispense soda action. With this interpretation, the entire interaction of the user depositing a haf doar and the machine dispensing a soda is performed as two actions. In the transition axiom method s interpretation, we aow the additiona possibiity that f (si) = f (si+) (even if si # si+). The interaction of buying a soda with a haf-doar coin coud invove dozens or hundreds of state transitions, ony two of which change the vaue off. What is gained by this new interpretation? In a rea soda machine, dispensing a soda coud invove hundreds of separate state transitions. If a specification asserts that this is just a singe action, then one has to say what it means for a machine operation with hundreds of state transitions to satisfy a specification asserting that it is a singe action. In the transition axiom method s interpretation, this is not a probem because the specification asserts that there is a state function that changes ony once during the dispensing of the soda; it says nothing about how many separate state transitions occur. The advantages of this interpretation are discussed ater. A forma specification shoud provide a the necessa y information to determine if an impementation is correct. However, from Figure 1, there is no way to determine if the impementation is supposed to consist of: (1) the entire soda machine, incuding the coin box and the soda rack, (2) a contro circuit inside the machine, or (3) a program for the soda machine s microprocessor. The choice of abes on the arcs may provide some cue, but surey this choice can have no forma significance. Can a soda machine, a circuit, and a computer program a be correct impementations of the same forma specification? A specification must be incompete if it does not distinguish between a mechanica device, a circuit, and a program. What is missing from Figure 1 is a specification of the interface--the mechanism by which the system communicates with the environment. The spec- ification must state whether communication is by depositing coins and dispensing cans, by raising and owering votages on wires, or by caing and returning from program procedures. The interface specification stipuates that the deposit quarter action may not be performed with a sedgehammer. The difference between depositing a quarter and wieding a sedgehammer, or between raising a 5 vot signa and raising a 5000 vot signa, can be described ony in terms of impementation detais. The interface must therefore be specified at the impementation eve. How is the interface specified? The environment and the system communicate by changing the vaues of state functions. For exampe, if we are specifying a circuit, then communication between the circuit and its environment is achieved by changing the vaues of state functions that represent the votages on wires4 To each wire w there might correspond a state function fw that represents the votage on the wire. The specification might permit the environment to communicate with the circuit by changing the vaue of jw to (the votage on the wire having some fixed vaue between 3.3 and 5.7 vots) when the vaue of fwg for some other wire w equas 0 f 1.2. (Despite the continuous range of votages, this can sti be considered a discrete system because the votage changes are assumed to be instantaneous.) To specify the interface, we must Specify how such interface state functions change. This can be done by the same method used to specify changes to interna state functions, such as the function f of the soda machine specification. Thus, no extra machinery need be added to the transition axiom method to specify the interface. In practice, we usuay don t bother specifying the interface in this way. Instead, we specify the interface in the impementation anguage, making it trivia to check that the interface is impemented correcty. For exampe, the wires connecting a circuit with its environment woud be specified directy in the hardware design anguage used to impement the circuit. Instead of specifying how the actua votages on a wire w change, we woud describe those changes with the hardware design anguage s primitives, such as a w := true. The actua votages woud not be described. How are program interfaces specified? The exact nature of the interface specification depends upon the programming anguage. For a Pasca procedure, the interface is specified by giving the name of the procedure, the types of its arguments, and the names and types of any goba variabes accessed by the procedure. For a Modua-2 package, the interface is specified by the definition modue [21]. 4 What we are reay specifying is not a circuit but a mathematica mode of the circuit. The state functions are the mathematica objects within the mode that represent the votages on the wires of the rea circuit. anuary 1989 Voume 32 Number 1 Communications of the ACM 35

5 This impies that we cannot specify a procedure independent;y of the anguage in which it is impemented. Shoudn t we be abe to write a singe specification of, say, a square root function that is independent of the anguage in which it is impemented? We are not specifying the anguage in which the procedure is impemented; we are just specifying the impementation of the interface. A system whose interface is specified as a Pasca procedure coud be impemented in assemby anguage; it need ony obey the same caing conventions as a Pasca procedure. Whie the specifications of a square root function for different programming anguages may be simiar, they wi not be identica. For exampe, how errors are handed wi depend upon whether or not the anguage provides an exception-handing mechanism. Separating the specification of a square root function into a common part and an interface-dependent part is a specification-anguage design issue that is addressed by Guttag, Horning, and Wing in Larch [6]. The infuence of the interface on the rest of the specification is especiay important in concurrent systems. It is shown in [14] that the specification of even so basic a property as first-come-first-served priority cannot be independent of the interface s impementation detais. You are saying that, even for the highest-eve specification, the interface must be specified at the impementation eve. Can t one hide these ow-eve impementation detais in the high-eve specification? The interface is specified by describing how interface state functions can change. We sha see beow how the changes to interna state functions can be specified hierarchicay; the same approach can be appied to the interface state functions. However, the high eve specification is not compete unti the interface is competey specified down to the impementation eve. A compete specification shoud eiminate the need for any communication between the user of the system and its impementor. For exampe, the specification of a contro circuit for a soda machine shoud contain a the information about that circuit s behavior needed by the person. designing the rest of the machine, which means that it must specify the actua votages on the wires. Whie a hierarchica decomposition of the interface may be quite usefu, it is ogicay just a method of organizing the high eve specification. I wi therefore not consider such a decomposition of the interface. Can interfaces be specified soey in terms of state functions? In addi.tion to interface state functions, we need to introduce the notion of who is responsibe for changing the vaues of these state functions. A specification of the sod,a machine interface must state that the environment (the user) performs the deposit quarter and deposit haf doar actions and the system (the machine) performs the dispense soda action. The specification of a procedure interface must state that the environment (the rest of the program) performs the procedure ca and the system (the procedure) performs the return. Usuay, actions are performed either by the environment or by the system. However, it is somet.imes usefu to assert which part of the environment performs an action. For exampe, to specify a process that interacts with its environment through both shared v.ariabes and CSP-stye operations [7], it may be usefu to distinguish actions performed by a communication channe ( I! and I? operations) from ones performed by other processes (setting shared variabes.)5 Why is it necessary to state who performs an interface action? Consider a Modua-2 package that impements a queue by providing put and get procedures. If we faied to specify that ony the environment can ca these procedures, then the specification woud be satisfied by an impementation that cas the put procedure itsef to cause random eements to appear in the queue. What is the genera form of a safety specification in the transition axiom method? A safety specification consists OE A set of state functions, partitioned into interface and interna state functions. A specification of the initia vaue of every state function. A set of actions, partitioned into interface and interna actions. For each interface action, a specification of who performs the action. (Interna actions are aways performed by the system.) A set of rues, caed transition axioms, that describe how each action changes the state functions. An interface state function may be changed ony by an interface action. In the soda machine exampe, there is a singe interna state function f whose initia vaue is I; the interface state functions have been eft unspecified. There are three actions, a of which are interface actio:ns: deposit quarter and deposit haf doar, performed by the environment, and dispense soda, performed by the system. The effect of the deposit quarter action is desc:ribed by a transition axiom asserting that the action can occur ony when f equas I, in which case it changes the vaue off to II, or when f equas II, in which case it changes the vaue off to III. The rues for the deposit haf doar and dispense soda actions are simiar, but a bit simper. A compete soda machine specification woud aso have to describe how these three actions change the interface state functions. Precisey what is the meaning of such a specification? The forma meaning of a transition axiom specification is a formua of tempora ogic. To give a rigorous definition of that meaning, one must define the forma semantics of tempora ogic and provide an agorithm for 36 Communications of the ACM ]anua y 1989 Voume 32 Number 1

6 A transating a specification into a tempora ogic formua. This is done in [12]. Instead of taking such a forma approach here, I wi try to provide an intuitive understanding of what a transition axiom specification means through carefu consideration of what it means to impement the specification. In deveoping an intuitive understanding of transition axiom specifications, it is usefu to know the genera shape of the formua underying a specification. I wi ignore the part of the specification having to do with who performs the actions. Let fit,.., fn be the interna state functions and g,,..., gm be the interface state functions of the specification. The forma meaning of the specification is a tempora ogic formua of the form6 3fi,..., fn s.t. x where X is a formua describing how the fi and gi are aowed to change. More precisey, X is a formua that constrains the sequence of states the system assumes by constraining the vaues of the state functions f< and gi on this sequence of states. Why is there quantification ony over interna state functions and not over interface state functions? The absence of quantification over the interface state functions is the forma expression of the observation that the interface must be specified at the impementation eve. The existentia quantification over the interna state functions aows compete freedom in how these state functions are impemented. Because the interface state functions are free (not quantified over) in the specification, those same state functions must appear in the impementation. A this shouid become cearer with the next exampe, which wi serve to address the question of what it means for an impementation to be correct. Another Specification of a Soda Machine Figure 2 is a soda machine specification written in an ad hoc anguage that resembes an ordinary decarative programming anguage. The interface procedures decarations provide the interface specification, which is omitted; the var decarations determine the range of vaues that can be assumed by x and y. Ange brackets denote that the operation they surround is a singe (atomic) action. Statement y performs an action consisting of a deposit-coin interface action pus the action of setting the vaue of y to the vaue of the deposited coin, the ony if cause (a notation invented just for this statement) meaning that the action can take pace ony if the vaue of x + y after the assignment is at most 50. Thus, the ony if cause disaows the possibiity of depositing a haf doar after a quarter is deposited. Figure 2 ooks ike a program. How is it interpreted as a transition axiom specification? To interpret Figure 2 as a transition axiom specifica- tion, we must describe the state functions, actions, etc. that it defines. The interna state functions are the variabes x and y and an additiona state function, et us ca it pc, that describes the program contro state; the interface state functions are presumaby specified (perhaps impicity) in the omitted part of the interface procedures. The state function x can assume the vaues 0, 25, and 50; the state function y can assume the vaues 25 and 50; and the state function pc can assume the vaues (Y,/3, y, 6, and 6. The initia vaues of x and y are unspecified; the initia vaue of pc is LY, indicating that contro is initiay at statement LY. There are five actions, one for each pair of ange brackets, that are abeed (Y... t. Actions y and t are interface actions, the former performed by the environment and the atter by the system; the rest are interna actions. The transition axioms for these actions specify the foowing aowed changes to the state functions. (Y: This action can occur ony when pc has the vaue (Y. It changes the vaue of x to 0, it changes the vaue of pc to & and it eaves the vaue of y unchanged. fi: Can occur ony when pc = /3. If x < 50 then it changes the vaue of pc to y, otherwise it changes the vaue of pc to c. It eaves the vaues of x and y unchanged. y: Represents the user action of depositing a coin. It sets the vaue of y equa to the vaue of the coin deposited, which must be either a quarter or a haf doar (because y can equa ony 25 or 50); it eaves the vaue of x unchanged. This action can occur ony when pc = y and the new vaue of y wi satisfy x + y : Can occur ony when pc = 6. It sets the vaue of x equa to its od vaue pus the od vaue of y, it eaves the vaue of y unchanged, and it sets the vaue of pc to p. c: Can occur ony when pc = t. It sets pc to LY and eaves the vaues of x and y unchanged. This action represents the dispensing of a can of soda. In this specification, x and y ook ike ordina y program variabes, but pc seems strange. Isn t there a fundamenta difference between the state function pc and the state functions x and y? interface procedures deposit-coin ; dispensesda.. ; var z: {0,25,50}; y: {25,50}; begin oop a: (I := 0); f: whie (z < 50) do 7: ( y := deposit-coin ony if z + ynnew < 50); 6: (z:=z+y) od; c: ( dispensemfa) end oop Note that the interface state functions gj are free variabes in the formua; the significance of this is discussed beow. FIGURE 2. Another Specification of a Soda Machine January 1989 Voume 32 Number 1 Communications of the ACM 37

7 No. To describe the execution of a program written in a decarative programming anguage, we must describe how the program contro position changes as we as how the vaues of variabes change. The programmer cannot expicity refer to the program counter, but its vaue is just as much part of the program state as is the vaue of an ordinary variabe. A programmer often has the choice of whether to use an extra variabe or a more compicated contro structure to represent the state of a computation. Is eve y program a specification? Yes. A program written in any programming anguage can be interpreted as a transition axiom specification. A major task in writing a compier from a source anguage to a target anguage is to represent, in the target anguage, the state functions specified by the program, incuding ones ike pc and the procedure-caing stack that a.re not expicity decared. A program written in a higher eve anguage is a specification of the object code produced by the compier. The ony difference between a program and a higher-eve specification is that the program is impemented by the compier without human intervention. f any program is a specification, why not write specifications iin an ordina y programming anguage instead of devising specification anguages? This can be done. However, programming anguages are const.rained by the requirement that programs must be compied into reasonaby efficient code. Because specifications do not have to be compied, specification anguages can permit simper specifications than can be written in programming anguages. Aso, programming anguages tend to encourage overy restrictive specifications. For exampe, in most programming anguages it is easy 1.0 state that one action must foow another but hard to state that two actions can be performed in either order. Such anguages encourage specifications that unnecessariy constrain the order in which actions must be performed. What kind of constructs can specification anguages use that programming anguages cannot? The primary programming anguage construct for indicating expicit state changes is the assignment statement. In a specification anguage, the assignment statement can be extended to aow an arbitrary reation between the od and new vaues of state functions. For exampe, statement y of Figure z can be described as the foowing reation between the od and new vaues of the variabes: (Y L?W = deposit-coin) A (x,,, = x,d) A (Y,W + x,1,, 5 50) where deposit-coin is some expression invoving od and new vaues of interface state functions that is presumaby defined by the omitted interface specification. An ordinary assignment statement is a specific form of reation in which the new vaue of a variabe equas (11 an expression invoving ony the od vaues of variabes. However, one can have more genera reations, such as add = sin2b,ew + 3 cos b,,, which expresses a reation between the new vaue of the variabe b and the od vaue of the variabe a. Such a reation cannot be expressed in a programming anguage because it cannot be compied into efficient code, but there is no reason not to aow it in a specification anguage. A transition axiom for an action, which determines the changes to state functions aowed by the action, is just such a reation between od and new vaues of state functions. For exampe, the transition.axiom for statement y is obtained by conjoining reation (), which asserts how x and y may change, = Y) A (p&xv = 6) The atter reation asserts how pc may change and incudes the requirement that the action can be performed ony when the initia vaue of pc equas y. The program of Figure 2 can be repaced by a set of five transition axioms of this form. However, the specification is easier to foow if we use ordinary programming anguage constructs ike ; and whie to describe impicity how the vaue of pc may change instead of expicity writing the reations between its od and new vaues. Figures 1 and 2 are two different specifications of the soda machine. How are they reated? They are equivaent-assuming that they are competed with the proper interface specifications. In other words, each one is a correct impementation. of the other. I wi show that Figure 2 correcty impements Figure 1. Demonstrating the converse requires some concepts that wi be introduced with another exampe. The interpretation of Figure 1 as a transition axiom specification asserts the existence of a state Eunction f with certain properties. To prove that Figure 2 satisfies this specification, we must demonstrate the existence off. This is done by defining f in terms of the state functions x, y, and pc, whose existence is asserted by the interpretation of Figure 2 as a transition axiom specification. We first observe that x < 50 w:hen pc = y and x + y 5 50 when pc = 6. (This is proved by showing that these two assertions are true initiay and are eft true by every action.) The vaue off is defined by the expression in Figure 3, written using Dijkstra s if construct.7 Finay, we show that, with this definition off, every action aowed by the specification of Figure 2 either eaves f unchanged or corresponds to an action (a change off) aowed by the specification of Figure 1. The reader can check that actions (Y, p, and (I do not change f. For exampe, cy can be executed ony when pc = CY, in which case f = I, and its execution sets pc = /3 Note that Figure 3 is not a program: it is just an ordinary mathematica definition off as a function of x. y, and pc written with Dijkstra s notation. 38 Communications of the ACM Januay 1989 Voume 2.2 Number 1

8 and x = 0, which eaves f equa to I. The reader can aso check that execution of y corresponds either to a deposit quarter or a deposit haf doar action aowed by Figure 1. For exampe, suppose y is executed starting in a state with x = 25. Since it can ony be executed when pc = y, this impies that initiay f = II. The specification of the y action impies that, starting with x = 25, it can change the vaues of x, y, and pc ony by setting y to 25 and pc to 6, which makes f = III. This change of the vaue off from II to III is permitted by the deposit quarter action of Figure 1. The reader can check that executing y starting with x = 0, the ony other possibiity, aso yieds a change off aowed by the deposit quarter or deposit haf doar action of Figure 1, and that executing t changes f as aowed by the dispense soda action of Figure 1. Is this a there is to the proof? We have not proved that Figure 2 correcty impements the interface of Figure 1. This requires showing that deposit-coin and dispense-soda are correct impementations of the corresponding actions of Figure 1, which we cannot do because neither they nor the interface of Figure 1 have been specified. How can we formaize the informa reasoning used in the proof? Let a state vector for the specification of Figure 2 be a tripe of possibe vaues of x, y, and pc, and et a state vector for the specification of Figure 1 be a possibe vaue off (either I, II, or III). To define fin terms of x, y, and pc, we defined a mapping F from state vectors of Figure 2 to state vectors of Figure 1. For exampe, F(0, 25, 6) = II means that f = II when x = 0, y = 25, and pc = 6. For any action E, et A, denote the transition axiom for 5. This is a reation between od and new vaues-in other words, a set of pairs of state vectors. For exampe, the pair ((0, 50, r), (0, 25, 6)) is in A, because it is possibe to execute y starting with x = 0, y = 50, and pc = y and ending with x = 0, y = 25, and pc = 6. Let A, and Az denote the set of actions of Figures 1 and 2, respectivey. Formay, we proved the theorem v.$ E Az V(v, w) E At 37 E A1 s.t. (F(v), F(w)) E A, ifpc= a -+f=i!l pc=porpc=.y-+ifz=o -+f=i C r=25-+f=ii 0 z = 50 + f = III (impossibe if pc = y) ALI pc = 6 -+ifs$y=25-rf=ii C z+y=50-+f=iii 0 z + y = 75 - impossibe fi pc = E - f = III fi FIGURE 3. Definition off in terms of x, y, and pc This formua has the foowing Engish transation, where bracketed expressions indicate the correspondence with the formua: for every action [t] of Figure 2 [in AZ] and every change to the vaues of x, y, and pc [from D to w] aowed by this action [(v, w) in A,], there exists an action [q] of Figure 1 [in A,] such that the corresponding change to the vaue off [from F(v) to F(w)] is aowed by that action [(F(v), F(w)) is in A,]. Exacty what does this prove? The forma meaning of the specification of Figure 1 is a formua 3f s.t. X1, where X1 is a formua describing how the vaue off is aowed to change; the meaning of Figure 2 is a formua 3x, y, pc s.t. X2, where XZ describes how the vaues of x, y, and pc are aowed to change. We proved the formua (3x, y, pc s.t. X,) > (3f s.t. X,) Thus, correctness of an impementation means simpe ogica impication: the specification is impied by the (specification of the) impementation. This impication was proved by proving Xz 3 ir,, where ir, is the formua obtained by substituting for f in X1 its expression in terms of x, y, and pc defined in Figure 3. In other words, assuming the existence of the state functions x, y, and pc satisfying Xz, we proved the existence of a state function f satisfying X1 by expicity constructing the required f in terms of x, y, and pc. In a compete specification, X1 and Xa woud aso describe the aowed changes to the interface state functions. However, because there is no quantification over interface state functions, this type of argument can work ony if X1 and X, contain the same interface state functions, and the behavior of those interface state functions asserted by X1 is impied by the assertions about their behavior made by X2, This is the forma statement of the observation that the interface must be specified (in X,) at the impementation eve (using the same state functions and interface actions as in X,). The proof that Figure 2 correcty impements Figure 1 can be reduced to ogica impication because both specifications are expressed by formuas in the same ogica system. This in turn is possibe ony because we interpret the state-transition diagram of Figure 1 in terms of the state function f. If Figure 1 were interpreted as specifying the behavior of a three-state machine whie Figure 2 specified the behavior of a SOstate machine, then they woud express formuas in different ogica systems and it woud not be cear what correctness of an impementation meant. Traditiona definitions of correctness of an impementation, invoving mappings on behaviors, have ignored probems that arise in specifying the interface. See [13] for further discussion of this issue. A Database Let us now consider a toy specification of a database concurrency contro mechanism. Cients of the database issue operations by caing an exec procedure with ]anuay 1989 Voume 32 Number 1 Communications of the ACM 39

9 arguments indicating the operation to be performed. There are two arguments: op, indicating the change to the database and res, indicating the vaue to be returned. (I assume that, as in Modua-2, procedures may return vaues.) These arguments are described formay as functions. Athough the exec procedure may be caed concurrenty by mutipe cients, the operations are to be performed as if they occur in a seria order. In other words, the database operations are to be performed as if they were atomic.8 The specification is given in Figure 4, using programming anguage notation. The interna state function data represents the state of the database. The interface is specified as a procedure ca. There is a singe interna action CL In this action, op and res denote the arguments of the procedure ca, and exec is the vaue that is returned by the procedure. The procedure ca and return are interface actions that are not expicity specified. How is Figure 4 interpreted as a transition axiom specification? The interface specification must contain state functions whose vaues indicate the set of processes currenty executing the exec procedure-that is, the set of processes that executed a ca that has not yet returned. There must aso be state functions that indicate the foowing information for each such process: The vaues of op and res. The program contro ocation, indicating whether the process is executing the ca, is at contro point LY, or is executing the return. The vaue of exec (the vaue to be returned), if the process has executed action CL Figure 4 seems to specify that the entire database operation must be done as a singe atomic action; doesn t this rue out concurrency? The specification asserts the existence of a state function data that changes atomicay; it does not assert that changes to the database must actuay be performed atomic,ay. Figure 2 impements Figure 1 even though the operations of depositing a haf doar and dispensing a can of soda consist of two atomic actions in Figure 1 and six atomic actions in Figure 2. The impementation was proved correct by defining fin such a way that In databnse circes, atomicity often means that a faiure cannot resut in a partiay competed operation. The possibiity of faiure is not considered in this exampe. type dbase :. ; vaue :.,. ; opfcn : dbase -+ dbase; resfcn : dbase -) vaue; interna state function data : dbase; procedure ezec(op: opfcn; res: tesfcn) : vaue begin a: (data,,, = op(data,d) A eiec,ew = res(data&) end FIGURE 4. A Database Specification ony two of those six actions change f, doing 130 as aowed by Figure 1; the other four actions eave f unchanged. In the same way, the change to the database, which is represented by executing the singe atomic action a! in Figure 4, can be impemented as a sequence of thousands of atomic actions. Correctness of the impementation means that the state function data can be defined as a function of the impementation state fun ctions in such a way that ony one of those thousands (of atomic actions changes its vaue, doing so as indicated by Figure 4. The state function must be defined so that a singe atomic action causes the entire database operation, which coud be arbitrariy compex, suddeny to be performed-even though each atomic action makes ony a sma change to the actua database. How is this possibe? The ony way to understand how it is done is by working out an exampe. One such exampe is the specification and impementation of a FIFO queue in 11121, where the specification asserts that the operations of adding and removing an eement from the queue are atomic, but an impementation that adds and removes eements one bit at a time is proved correct. The proof method is a generaization of assertiona methods for proving safety properties of concurrent programs [18]. In these assertiona methods, one constructs an invariant, which is a booean state function whose vaue never changes; in the transition axiom method, one constructs state functions whose vaues change ony in the manner prescribed by the transition axioms. Another Database Specification The concurrency contro mechanism specified by Figure 4 is caed seriaization [5] because database operations are executed as if they occurred in some seria order. However, Figure 4 is not the most genera specification of seriaization because it requires that the actua reading and writing of the database occurs between the ca of exec and the subsequent return, which impies that if one ca to exec returns before another ca is initiated, then the operation performed by the first ca precedes the operation performed by the second in the seriaization order. Some concurrency contro agorithms that are considered to be seriaizabe do not have this property. So, et us now consider the more genera specification of a seriaizabe database given in Figure 5. The interface of the new specification is the same as that of Figure 4: a procedure named exec with two arguments that specify the operation. However, instead of performing the operation immediatey, action /3 chooses a competey arbitrary vaue to return (the vaue V) and saves that vaue together with the arguments of the procedure ca in saved-ops, a bag of operations to be performed ater.g A separate, asynchronous a&on y at A bag, aso caed a mutiset, is a set in which the same eemem can appear more than once. 40 Communications of the ACM January 1989 Voume 32 Number 1

10 some ater time wi perform the operation. The interna process keyword denotes that its actions are performed by the system independenty of actions performed through cas to the exec procedure. The cause v = r(gdata,d) in the specification of action y means that the action is performed ony if the database state is such that the resut that was aready chosen (by the /3 execution that put the tripe (o, r, v) in the bag savedops) was the correct one. Since this is a safety specification, it does not assert that y wi ever do anything; it simpy asserts that y cannot perform a database operation uness the resut agrees with the one that the,f3 action had aready decided to return. We must aso require the iveness property that every operation saved in saved-ops is eventuay performed. Section 3 indicates how this property is specified. This specification is competey bizarre; it requires that the exec procedure guess what the correct resut of the database operation wi be before actuay executing it. How can one possiby impement such a specification? Figure 5 is bizarre ony if viewed as a description of how the exec procedure is to be impemented. A program describes how something is to be done, whie a specification describes ony what is to be done. Figure 5 describes the observabe behavior of the database system; it makes no forma assertion about how that behavior is to be impemented. It is important to reaize that even though a transition axiom specification may ook superficiay ike a program, apparenty describing how the system is to be impemented, it reay specifies ony the externay visibe behavior-that is, how the interface state functions may change. Interna state functions such as saved-ops need not appear in any obvious form in the impementation s data structures. Indeed, as I wi expain beow, they need not appear at a. If Figure 5 is a more genera specification than Figure 4, then Figure 4 shoud impement Figure 5. However, the type dbase :.. ; vaue :... ; opfcn : dbase - dbase; resfcn : dbase -t vaue; interna state function gdata : dbase; saved-ops : bag of (opfcn, resfcn, vaue); procedure ezec(op: opfcn; res: resfcn) : vaue begin end P: (31 s.t. ezecnerr = VI A saved-ops,, = saved-ops,,d u {(op, ws, v)} ) interna process begin oop y: (3(0, r,zr) E saved-ops,,d s.t. gdata,,, = o(gdataod) A v = r(gduta,,d) A saved-ops,,, = saved-ops,,d - {(O,T,B)}) endoop end FIGURE 5. A More Genera Database Specification impementation executes fewer actions than the specification, a singe a! action performing the database operation that the specification asserts is done by a /3 action (to put the operation in saved-ops) and a 7 action (to change the database). How do we prove that this is a correct impementation? As in the proof for the soda machine exampe, we must define the specification state functions gdata and savedops in terms of the impementation state function data. We et gdata equa data and define saved-ops aways to equa the empty bag. Again we must show that every action of the impementation changes the vaues of the specification state functions as aowed by the specification actions. However, we drop the requirement that each impementation action corresponds to at most a singe specification action and aow it to correspond to a sequence of specification actions. There is ony one interna action in Figure 4: the action CY. Executing action (Y produces the same changes to gdata and savedops as an execution of a /3 action foowed by an execution of a y action. The y action immediatey executes the operation that the fi action puts in saved-ops, the tota effect being to eave saved-ops empty and to produce the required change to gdata. Is one aways aowed to impement a sequence of specification actions with a singe impementation action? Two conditions must be satisfied for a sequence of specification actions to be impementabe by a singe impementation action: At most one of the specification actions can be an interface action. A the actions (the specification actions and the impementation action) must be performed by the same agent-either the system or the environment, These two conditions rue out pathoogica impementations. The case of severa specification actions impemented with a singe action arises ony when demonstrating that one specification is at east as genera as another. (I just demonstrated that Figure 5 is at east as genera as Figure 4.) In rea impementations, a singe specification action is usuay impemented with dozens or even thousands of separate actions. What is the forma justification for the correctness of impementing severa specification actions with a singe action? Reca that the formua represented by a transition axiom specification is of the form 3fi,..., f,, s.t. X, where the fi are the interna state functions. The reason we are aowed to impement severa actions with a singe one ies in the forma meaning, given in [4], of existentia quantification of a state function. In proving that the formua represented by the impementation impies the formua represented by the specification, the existentia quantification over the interna state functions aows one to consider the execution obtained by spitting one action into severa successive actions to be equivaent to the origina execution if the extra actions change ony the interna state functions. However, an Ianuary 1989 Voume 32 Number 1 Communications of the ACM 41