A Hoare Logic for Concurrent Objects with Asynchronous Method Calls. Johan Dovland, Einar B. Johnsen, and Olaf Owe

Transcription

1 Universitetet i Oslo Institutt for informatikk A Hoare Logic for Concurrent Objects with Asynchronous Method Calls Johan Dovland, Einar B. Johnsen, and Olaf Owe Research report 315 ISBN (Revised version) December 2004 Revised March 2006

2

3 A Hoare Logic for Concurrent Objects with Asynchronous Method Calls Johan Dovland, Einar Broch Johnsen, and Olaf Owe Department of Informatics, University of Oslo PO Box 1080 Blindern, NO-0316 Oslo, Norway Abstract The Creol language proposes high level language constructs to unite object orientation and distribution in a natural way. In this report, we show how the semantics of Creol programs may be defined in terms of standard sequential constructs. The highly nondeterministic nature of distributed systems is captured by introducing communication histories to record the observable activity of the system. Hoare rules expressing partial correctness are then derived based on the semantics. 1 Introduction The importance of inter-process communication is rapidly increasing with the development of distributed computing, both over the Internet and over local networks. Object orientation appears as a promising framework for concurrent and distributed systems [25], but object interaction by means of method calls is usually synchronous. The mechanism of remote method calls has been derived from the setting of sequential systems, and is well suited for tightly coupled systems. It is clearly less suitable in a distributed setting where the components are loosely coupled. Here synchronous communication gives rise to undesired and uncontrolled waiting, and possibly deadlock. Asynchronous message passing gives better control and efficiency, but does not provide the structure and discipline inherent in remote method calls. The integration of the message concept in the object-oriented setting is unsettled, especially with respect to inheritance and redefinition. Intuitive high-level programming constructs are needed to unite object orientation and distribution in a natural way. The Creol language [26, 28] proposes programming constructs for concurrent objects based on processor release points and a notion of asynchronous method calls, allowing method overtaking. An object is assumed to encapsulate a processor, and processor release points are used to influence the implicit internal control flow in the objects. This reduces time spent waiting for replies to method calls in a distributed environment and allows objects to dynamically change between active and reactive behavior (client and server roles). The Creol language has a formal operational semantics defined in rewriting logic [32], in which method calls are reflected by pairs of asynchronous messages [27,29], allowing message overtaking. The result extends programming with so-called future variables [7, 10, 12, 41, 42]; the caller may continue its computation until the return value of the call is explicitly needed in the code. If the reply has not arrived at this point, the object must wait unless it can proceed with other pending computations. For this purpose, the future variable programming 1

4 style is extended in Creol by introducing interleaved method evaluations in objects. This is done by defining potential processor release points by means of nested guards in method bodies. Guarded commands were introduced by Dijkstra [17] to capture non-deterministic choice as a basic programming construct. Here, guards will influence the control flow inside concurrent objects. In particular nested guards are used to release processor control, allowing the object s invoked and enabled methods to compete for the free processor. There are three basic interaction models for concurrent processes: shared variables, remote method calls, and message passing [3]. Rather than sharing variables, objects encapsulate local variables, and inter-object communication is more naturally modeled by (remote) method calls. With the remote method invocation (RMI) model, an object is reactivated by a method call. Control is transferred with the call so there is a master-slave relationship between the caller and the callee. A similar approach is taken with the execution threads of e.g. Hybrid [34] and Java [20], where concurrency is achieved through multithreading. However, the interference problem related to shared variables reemerges when threads operate concurrently in the same object. Hybrid avoids this because all methods are serialized. In contrast, non-serialized methods in Java can access variables simultaneously. Reasoning about programs in this setting is a highly complex matter [1,11]: Safety is by convention rather than by language design [9]. Verification considerations therefore suggest that objects should have serialized methods. However, when restricting to serialized methods, the calling object must wait for the return of a call, blocking for any other activity in the object. In a distributed setting this limitation is severe; delays and instability due to distribution may cause a lot of unnecessary waiting. Furthermore, a non-terminating method will block access to the object, which leads to difficulties for combining active and passive behavior in the same object. The asynchronous method calls proposed by Creol strike a balance between serialized and non-serialized methods. In this report, we argue that these language constructs provide mechanisms for reasoning control which are considerably better than those needed for nonserialized methods, while they are better adapted to the distributed setting than serialized methods as argued above. Reasoning about non-terminating systems will be in terms of invariants on communication histories. Hoare logic [4,14,21] will be used to establish the set of possible local histories. Hoare rules are proposed to capture the asynchronous method calls and processor release points of Creol. The report is organized as follows: in the next section we define communication histories and relate these to the execution of an object system. In order to emphasize on local reasoning we also show how these histories may be restricted to single objects. Section 3 summarizes the Creol language and introduces a kernel CreolK which is a subset of the full language. Section 4 gives an overall view of reasoning at the class level in terms of invariants. In Section 5 we give semantics to the CreolK statements in terms of well-known program statements, and in Section 6 we derive reasoning rules based on the introduced semantics. Section 7 extends the proof system with rules for the statements outside the kernel language. Section 8 provides some examples and Section 9 discusses completeness of the proof system. The last two sections discusses some related work and draws some conclusions. 2 An Abstract View of Distributed Systems An execution of a distributed system can be represented by a sequence of interleaved communication events. In the case of non-terminating executions, the sequences are infinite. 2

5 However, infinite sequences are not easy to reason about. In order to avoid infinite sequences, system specifications may be expressed in terms of the finite initial segments of the executions, which express the abstract states of the system. These sequences are commonly referred to as communication histories [13] or traces [23]. An invariant which applies to all abstract system states, will consequently be a predicate on finite traces which holds for all sequences in the prefix-closure of the set of executions. We refer to these predicates as history invariants. These invariants express safety properties in the sense of Alpern and Schneider [2]. In the object oriented setting, objects have explicit identities and communication events between named objects will represent initiations and completions to remote method calls. The local state of a subsystem may be captured by projection on the global history, restricting it to the communication events related to the subsystem. In particular, the local communication history of an object is obtained by restricting the global history to events reflecting calls to the object s methods from other objects in the environment and calls by the object to methods of other objects in the environment. We will in the following apply local histories to obtain local reasoning. In order to reason about distributed object systems, we define specification predicates capturing (allowed) communication patterns [27, 29, 30]. For non-terminating systems, these predicates typically express invariant requirements on the (local) communication history. For open systems, our specification predicates will follow the assumption commitment (or relyguarantee) paradigm [31], which allows compositional reasoning. A mythical variable is a variable which is introduced in the program for reasoning purposes. Mythical variables do not influence the behavior of the program and need not be included in the final program code [14]. In order to refine interface specifications to the Creol class level, we use a mythical history variable, a sequence of communication events which is implicitly extended with events representing invocations and completions of object methods at appropriate places in the programs. In the asynchronous setting, the object may only update the local history with events emitted by the object, and with events emitted by objects in the environment. The latter may occur at any time. Section 6 considers verifying the effect of operations by means of Hoare logic. For specification purposes, the history will be constructed by sequence suffixing, using right append as the constructor in contrast to prefixing by means of left append. The history thus captures the abstract state rather than the continuation of the execution. Hence, the history is always available for reasoning, as an abstract representation of the state, encapsulating object attributes, from which we can extract information. Consequently, the correct behavior of the specified object can be determined by a predicate on the history. Choosing the prefix constructor instead would bring us to a recursive setting, similar to process algebras such as CSP. In this case, the history is not available for reasoning and information concerning the state must be passed along in process parameters that reveal parts of the internal structure of the program. An illustrative example here is the formalism CSP-OZ [19], which combines CSP with Object-Z. In this formalism, objects specified in Object-Z are represented as CSP processes by including all attributes as process parameters. With the suffix constructor, specifications do not need to reveal the internal structure of the program in this manner, so they are in this sense more abstract than the corresponding process algebraic specifications. In particular, recursive definition of processes and resulting fix-point semantics are avoided. 3

6 2.1 Communication Events This section introduces some structure to the communication messages, which will be used in order to give a formal description of communication histories for object oriented systems with asynchronous method calls. Due to the asynchronous setting considered, method overtaking is allowed. In particular, replies to two method invocations to the same method in an object may arrive in the opposite order of their invocations. Therefore, method calls come equipped with label values. It is assumed that the pair o,l forms a unique identifier for a method call, where l is a label and o the identity of the calling object. Let Obj, Mtd, and Label denote the types of objects, methods and label identities, respectively. The type Label has a total ordering. Also let Data be a (further) unspecified variable type representing values which may occur as actual parameter values to method calls, and Kind the enumeration type ranging over {init, comp}. We let List[T] denote the type of lists of elements of type T. Definition 1 (Messages) Let o,o Obj, m Mtd, l Label and x,y List[Data]. The set IMsg is defined as all possible tuples o,l,init,o,m,x, represented graphically by o l o.m(x). The set CMsg is defined as all possible tuples o,l,comp,o,m,y, represented graphically by o l o.m(y). The set Msg of all possible messages is defined by Msg == IMsg CMsg. The invocation of a method m of object o by object o can be seen as passing a message from o to o, and the reply can be seen as passing a message the other way, from o to o. One may therefore think of the defined tuples as reflecting invocations and completions of method calls. In particular, method invocations are reflected by messages from the set IMsg, of kind init, and method completions by messages from the set CMsg, of kind comp. In the graphical notation, init is represented by the right arrow, and comp by the left arrow, illustrating which way a message is sent. The first and fourth elements of the tuples represent the objects calling and executing the method, respectively. For calls to methods without formal parameters, the list of data values in the initiation message will be empty, and for methods without output values, the list of data values in the completion message will be empty. Based on Definition 1 we can define functions to extract information about the components of messages. Definition 2 (Decomposition of messages) Let o,o Kind, and e List[Data]. Define Obj, m Mtd, l Label, k o,l,k,o,m,e.caller == o o,l,k,o,m,e.callee == o o,l,k,o,m,e.label == l o,l,k,o,m,e.mtd == m o,l,k,o,m,e.kind == k o,l,k,o,m,e.par == e 2.2 The Communication History We now assume that communication between system objects up to present time is recorded in a finite sequence of type Seq[Msg], which we refer to as the communication history of the 4

7 system. Finite sequences are defined by the empty (ε) and right append ( ) constructors. In addition, the following syntax is used: concatenation, right rest rr, left rest lr, left term lt, right term rt, length #, and m h. The definitions are given in Appendix A.1. The message decomposition functions of Definition 2 are lifted to range over sequences, returning a sequence of the specified message element. For instance, _.label is a function constructing the sequence of labels from the communication history, defined inductively by ε.label == ε (h m).label == h.label m.label Projection of the history to a subset of the communication messages will often be needed. Definition 3 (Projection) Let h : Seq[Msg] and S Msg. We define the projection operator _/_ : Seq[Msg] Set[Msg] Seq[Msg] inductively by ε/s == ε h m/s == if m S then (h/s) m else h/s fi The restriction of the communication history to the invocation messages made by o is defined as h/o == h/{m : Msg (m.caller = o m.kind = init)}, and restriction to completion messages addressed to o is defined as h/o == h/{m : Msg (m.caller = o m.kind = comp)}. We now define two functions init and comp to check whether an initiation or a completion corresponding to a caller and a label value exists in the history. Definition 4 (Init, Comp) Let h : Seq[Msg], o Obj, and l Label. Define init,comp : Seq[Msg] Obj Label Bool as: init(h,o,l) == l (h/o ).label comp(h,o,l) == l (h/o ).label The history sequence will be used to model the communication history of a distributed object system, communicating by means of method calls. Initially, the history sequence is empty. Every time an invocation message is sent from an object in the system, the history sequence is extended by means of right append with a message of type IMsg reflecting the invocation. Likewise, sending of completion messages is recorded on the history by messages of type CMsg. Given an arbitrary distributed system based on asynchronous communication, there are in general no restrictions on when an object can emit an invocation message, since no synchronization is involved. There are however restrictions on completion messages. A completion message must match a corresponding invocation message, and it must occur after the invocation message in the recorded history. Together with a formalization of the fact that all invocation messages sent from a particular object must be equipped with unique labels, this leads to a notion of wellformedness for histories. The function incr expresses that a sequence is strictly ordered (defined in Appendix A.1). Definition 5 (Wellformed histories) Let h : Seq[Msg], o,o Obj, m Mtd, l Label, and e List[Data]. The function wf : Seq[Msg] Bool is defined by induction as wf (ε) == true wf (h o l o.m(e)) == wf (h) incr((h/o ).label l) wf (h o l o.m(e)) == wf (h) init(h/(o.m),o,l) comp(h,o,l) 5

8 where h/(o.m) denotes the restriction of h to messages involving the method m provided by object o. For wellformed histories, every recorded invocation message sent from a particular object is equipped with an unique label. Note that label values are generated in an increasing order by each caller, and thus a callee may detect the original order of invocation messages emitted by a given caller, even though they may arrive in a different order. Related function definitions specific to communication histories may be found in appendix A Local History Projections In order to reason locally about a particular object o, we will consider the local communication history h/o of an object o, defined as h/o == h/{m : Msg (m.caller = o m.callee = o)}. By extension, we denote by h/o the projection of h on a set of objects O, defined as h projected on the union of the sets of communication events associated with each object in O. It is useful to distinguish the messages on the local history into four categories: 1. Messages reflecting invocations of methods provided by o: o l o.m(e). 2. Messages reflecting completed execution of a method provided by o: o l o.m(a). 3. Messages reflecting invocations by o of methods available in objects in the environment: o l o.m(e). 4. Messages reflecting the completion of calls initiated by o to methods available in objects in the environment: o l o.m(e). Messages in categories 1 and 2 form pairs which reflect calls made by objects in the environment to methods provided by o, and messages in categories 3 and 4 form pairs which reflect calls made by o to methods provided by objects in the environment. Denote by IN o the union of categories 1 and 4, i.e. incoming messages to o; and by OUT o the union of categories 2 and 3, i.e. messages sent by o. IN o == {m : Msg (m.caller = o m.kind = comp) (m.callee = o m.kind = init)} OUT o == {m : Msg (m.caller = o m.kind = init) (m.callee = o m.kind = comp)} These two sets may overlap when o and o denote the same object. At the interface level we want to specify communication between an object and its surroundings. Interface specifications therefore refer to the history restricted to events where the caller and callee are different objects. At the class level however, we consider internal communication as well and refer to the local history h/o including invocations of local methods. Lemma 1 (Preservation of wellformedness) Let h be a wellformed history sequence and o an object identifier. Every local projection h/o is also wellformed. Proof. Follows from Definitions 3 and 5. Consequently, all properties of wellformed histories also apply to local histories. In the following, we use H to denote a wellformed history over some set S Msg involving a set of 6

9 objects, and H o to denote a (wellformed) local history for an object o. The local history of an uninstantiated object is ε. Two local histories H o and H o may be composed if they are compatible [38,39]. In our case, compatibility is achieved by projection, i.e. H o and H o are composable if there exists a history H such that H/o = H o and H/o = H o. Let H G denote a global history which records every message sent between objects in the system. It follows that H G /o = H o for every object o in the system. 3 A Language for Distributed Concurrent Object Systems This section summarizes Creol [26, 28], a programming language for distributed concurrent objects, focusing on the communication aspects of the language: asynchronous method calls and processor release points. Concurrent objects are potentially active, encapsulating execution threads. Objects have explicit identifiers: communication takes place between named objects and object identifiers may be exchanged between objects. All object interaction is by means of method calls. This report ignores inheritance relations in Creol. 3.1 Classes and Objects At the programming level, attributes (object variables) and method declarations are organized in classes in a standard way. Objects are dynamically created instances of classes. The attributes of an object are encapsulated and can only be accessed via the object s methods. Among the declared methods, we distinguish the method run, which is given special treatment operationally. After initialization of the object, the run method, if provided, is invoked. Apart from run, declared methods may be invoked by other objects. These methods reflect passive, or reactive, behavior in the object, whereas run reflects active behavior. We will refer to the invoked method instances as the object s processes. Object activity is organized around an external message queue, which contains incoming messages, and an internal process queue, which contains pending processes. Methods need not terminate and may be temporarily suspended on the internal process queue. Objects are typed by interface. Creol is strongly typed, which ensures that each method invocation o.m where I is the declared interface of o, the actual object o will support I and the method m is understood. 3.2 Asynchronous Methods Methods in Creol are invoked in an asynchronous way [26, 28]. Methods are implemented as a sequence of guarded commands await g;s, to be evaluated in the context of locally bound variables. Due to the possible interleaving of different method executions, the values of an object s instance attributes are not entirely controlled by a method instance if it suspends itself before completion. However, a method may create local variables supplementing the attributes. In particular, the values of formal parameters are stored locally, but other local variables may also be created. An object can have several pending calls to the same method, possibly with different values for local variables. The local variables label and caller are reserved to identify the call and the caller for the reply, which is emitted at method termination. An asynchronous method call is made with the command l!o.m(e), where l Label is a unique reference to the call, o an object expression, m a method name, and e an expression list 7

10 with the supplied actual parameters. Labels are used to identify replies, and may be omitted in the syntax if a reply is not explicitly requested. No synchronization is involved and process execution may proceed after calling an external method until the return value is needed by the process. To fetch the return values from the queue, say in a variable list x, we ask for the reply to our call: l?(x). If the completion message has arrived, return values are assigned to x and execution continues without delay. If no reply to the call has been received, process execution is blocked. This interpretation of l?(x) gives the same effect as treating x as a future variable, e.g. [7, 42]. Although remote and local calls can be handled operationally in the same way, it is clear that for execution of local calls the calling process must eventually suspend its own execution. In particular, synchronous local calls are loaded directly into the active code. The syntax o.m(e;x) is adopted for synchronous (RPC) method calls, blocking the processor while waiting for the reply. Local calls need not be prefixed by an object identifier. 3.3 A Language with Processor Release Points In Creol, the control flow inside concurrent objects may be influenced by potential processor release points. These are explicitly declared in method bodies using guarded commands, as introduced by Dijkstra [17], but adapted to the following semantics: When a guard evaluates to false during process execution, the remaining process code and the values of its local variables are suspended to the internal process queue and the processor is released. After processor release, an enabled process from the internal process queue is selected for execution. Processor release points may be nested within the same local variable scope. Definition 6 The type Guard is constructed inductively as follows: wait Guard (explicit release) l? Guard, where l Label φ Guard, where φ is a boolean expression over local and object variables g 1 g 2 Guard and g 1 g 2 Guard, for g 1,g 2 Guard. Here, wait is a construct for explicit release of the processor. The reply guard l? succeeds if the completion message to the method invocation with label l has arrived. We allow composition of guards: g 1 g 2 and g 1 g 2 for guards g 1 and g 2. Evaluation of guards is done atomically. Finally, we define await l?(x) as an abbreviation for await l?; l?(x), and await o.m(e; x) as an abbreviation for L!o.m(e);awaitL?(x) for some fresh label variable L. Guarded commands can be composed in different ways, reflecting the requirements to the internal control flow in the objects. Let GS 1 and GS 2 denote the guarded commands await g 1 ;S 1 and await g 2 ;S 2. Nesting of guards is obtained by sequential composition; in a program statement GS 1 ;GS 2, the guard g 2 corresponds to a potential nested processor release point. Non-deterministic choice between guarded commands is expressed by GS 1 GS 2, which may compute S 1 only when g 1 evaluates to true or S 2 only when g 2 evaluates to true, and the whole non-deterministic construct is implicitly guarded by g 1 g 2. Note that the sentence await true is redundant, and consequently a non-guarded statement may be considered as a sentence guarded by true. Non-deterministic merge S 1 S 2 may be defined by S 1 ;S 2 S 2 ;S 1 Control flow without potential processor release is expressed by if and while constructs, and assignment to local and object variable lists is expressed as x := e for lists (with same length) of program variables x and expressions e, where x is a list of disjoint variables to which there 8

11 Syntactic categories. Definitions. g in Guard S in ComList C in Com v in Var x in Var_List e in Expr_List m in Mtd o in Obj_Expr l in Label φ in Bool_Expr g ::= wait φ l? g 1 g 2 g 1 g 2 S ::= C C; S C ::= skip x := e ( S ) v := new classname(e) if φ then S 1 else S 2 fi if φ then S fi while φ do S od S 1 S 2 S 1 S 2 l!o.m(e) l?(x) m(e; x) o.m(e; x) l!m(e)!o.m(e)!m(e) await g await l?(x) await o.m(e; x) Figure 1: An outline of Creol syntax. is write access. Note that there is read-only access to in-parameters of methods. Figure 1 summarizes the language syntax. With nested processor release points, the processor need not wait actively for replies. Pending processes or new method calls may be evaluated instead of blocking the processor. However, when the reply has arrived, the continuation of the original process must compete with other enabled pending processes in the internal process queue. 3.4 The Creol Kernel (CreolK) Before defining the semantics of Creol, we identify two sublanguages: the Creol base language CreolB, which is the sequential sublanguage of Creol, and has a well-known semantics [4, 5], and the Creol kernel, CreolK, which includes all the essential mechanisms for asynchronous method calls and processor release points. The syntax of the two sublanguages is given below: C B ::= skip x := e S 1 S 2 m(e;x) ( S ) S 1 ;S 2 if φ then S 1 else S 2 fi while φ do S od C NB ::= l!o.m(e) l?(x) await g CreolB is defined by restricting the syntactic category of commands C in Figure 1 to the sentences of C B, whereas CreolK restricts C to include both kinds of statements: C B C NB. The remaining constructs of Creol may be defined in terms of CreolK as follows: l!m(e) l!this.m(e)!o.m(e) L!o.m(e)!m(e) L!this.m(e) o.m(e; y) if o = this then m(e; y) else L!o.m(e); L?(y) fi await l?(x) await l?; l?(x) await o.m(e; x) L!o.m(e); await L?(x) if φ then S fi if φ then S else skip fi S 1 S 2 S 1 ;S 2 S 2 ;S 1 Here, the object expression this always evaluates to the current object, and L represents a fresh label variable. Note that synchronous calls to remote objects are simulated by asynchronous communication, whereas synchronous calls from an object to itself are performed directly (without involving any communication). 9

12 4 Class Invariants with Mythical Histories In a non-terminating system it is difficult to specify and reason compositionally about behavior in terms of pre- and postconditions. Instead, pre- and postconditions to method declarations are used to establish a class invariant. In order to facilitate compositional reasoning about Creol programs, the class invariant will be used to establish a relationship between the internal state and the observable behavior of class instances. The internal state reflects the values of class attributes and the observable behavior is expressed by a set of potential communication histories [29]. For this purpose, the class attributes are extended with a mythical history variable H and the code is extended with (mythical) statements to update the history variable for every output message generated by the program code. Mythical variables and statements are written in calligraphic font, in order to distinguish these from ordinary program variables and statements. Let FV [P] denote the set of variables which occurs free in a predicate P and let P x e denote the substitution of every free occurrence of x in P by the expression e. For a class C, we shall aim at establishing a class invariant I C, which ranges over class attributes (w) and the history sequence H, i.e. FV [I C ] w {H}. We will sometimes write this explicitly as I C (w, H). We consider an arbitrary object of class C, the invariant I C must be proved to hold for initial values of the class attributes. Consequently, we may assume that I C holds when the object processor starts execution of an invoked method, if we can verify that I C holds every time processor control is released. Due to Creol s nested processor release points, this can happen in two ways: method execution is completed, or guards in await sentences are not satisfied. If we can establish that the class invariant holds before processor control is released for both of these cases, it will be safe to assume that the class invariant holds every time a process starts or resumes execution. We will in the following section model Creol method bodies, and Section 6 presents reasoning rules which can be used to prove preservation of the invariant over method bodies. We will however start by giving the overall verification condition we have to consider when reasoning about methods. Let w m denote the variables local to a method m and assume that there is no overlap between these and names and the class attributes, i.e. w m w =. Ignoring type information, the method m may then be declared as: op m(in x out y) == var w m := Initvalues;body where the statement var w m := Initvalues denotes declaration of the local variables and concurrent assignment of their initial values. When reasoning about the method body, we will assume that the method has been invoked, so there must be a pending invocation message corresponding to this invocation somewhere on H. Upon method termination, a corresponding completion message is appended to the history, preserving wellformedness. For reasoning purposes, the update is explicitly represented. This leads to the following verification condition 10

13 { I C wf (H) init(h/(this.m),caller,label) comp(h,caller,label) x = (find(h,caller,label,init)).par} w m = Initvalues;body; H := H (caller label this.m(y)) { I C init(h/(this.m),caller,label) comp(h,caller,label) (1) where the precondition accounts for the assignment of the actual parameters to the formal parameter list x. The function find, defined in appendix A, looks up an event in the history. Our semantics allows local reasoning about class objects, and a global invariant may be defined in terms of local invariants. Given an object o of class C (denoted o : C) and a history H, the class invariant must hold for appropriate values of the class attributes: I o:c (H) w (I C (w, H)) this o The substitution replaces the free occurrences of this in I C with o, and the existential quantifier hides all attribute occurrences. We now define the prefix closed abstraction I o:c of I o:c: I o:c(h) h I o:c (H h) This reflects that the invariant I o:c need not hold when o is not in a quiescent state. The extension h of H reflects computations needed in order to establish the invariant. It follows that Io:C will hold in all possible local states although this may not be the case for I o:c. Finally, the global invariant I G on possible global communication histories may be derived. For a set O of objects and a history H, the global invariant can be defined as: I G (H) Io:C (H/o) o:c O Due to the prefix closure of local histories this invariant will hold in all possible global states. We will study composition of local histories in Section 5.2. A global communication history H G which satisfies the global invariant I G is total in the sense that asynchronous calls from an object to itself are recorded. An abstract global history without such internal events may be obtained by projection. 5 Encoding Asynchronous Method Calls in CreolB The base language CreolB consists of standard syntax and well-established semantics and proof system. In particular, Apt [4, 5] shows that this proof system is sound and relatively complete. In this section, the semantics of Creol will be defined by means of the CreolB semantics, and the next two sections will use the proof system for CreolB to derive sound Hoare rules for Creol. A Creol process with release points and asynchronous method calls is interpreted in CreolB as a non-deterministic program without shared variables, release points, and asynchronous method calls. The local history is captured by a local variable H in each class, using nondeterministic updates on H to mimic the current state of the local interaction history of the original Creol program. In order to capture an interleaving semantics in Creol, each atomic statement is interleaved with a non-deterministic extension of H mimicking asynchronous interaction with external objects. 11

14 5.1 Encoding CreolK in CreolB A CreolK program is translated to a CreolB program by a mapping..., defined below. All expressions and types are translated by the identity function. Creol classes, with methods and attributes, are translated directly to CreolB, with some implicit parameters added to the methods, and with this : Obj added as a class attribute. We consider a given class C with variable attributes w, and a given method m in this class with local variables and in- and out-parameters. Each method gets two implicit in-parameters, caller : Obj and label : Label, which store the object identifier of the initiator and label value of the call, respectively. As in Creol there is only read access to in-parameters. op m(in x 1 : T 1,x 2 : T 2,... out y 1 : U 1,y 2 : U 2,...) == var w m := Initvalues;body = op m(in x 1 : T 1,x 2 : T 2,...,caller : Obj,label : Label out y 1 : U 1,y 2 : U 2,...) == var w m := Initvalues; body ; H := H caller label this.m(y) The additional class variable H is a sequence of messages involving this, initialized to empty. CreolB allows non-deterministic assignment, which is denoted y := some x P(x), where y is a list of distinct variables of the same length and type as the list x, and x is chosen non-deterministically such that it satisfies the predicate P, if possible, otherwise the statement aborts. Capturing the environment. Reasoning about a Creol process cannot alone capture the concurrent activity of the asynchronously communicating object. In particular, the object may receive arbitrary input and other processes in the object may send output. We shall model this by certain non-deterministic extensions to the history variable H. For this purpose, we introduce two language macros for specific non-deterministic assignments: interleave represents activity by the environment when the object is not active, and release represents activity by the environment and also by other processes in the object, capturing release points. Define interleave as: interleave H := some h H h wf (h) h/out this = H/OUT this i.e. H is extended in a non-deterministic manner by some wellformed sequence of events, but output from this does not occur. It follows from this definition that predicates not restricting input to this, or not concerned with input to the object at all, are not affected by interleave. This expresses that this object does not have control over its environment, but predicates may however relate output-events to input-events. Especially, class invariants must fulfill this criteria, i.e. we have the following triple: {I C (w, H)}interleave {I C (w, H)}. This requirement means that we may omit interleave statements where the invariant is required to hold, such as before and after methods bodies. The second language macro, release, denotes the simultaneous assignment to the class attributes and H, and is defined as release w, H := some w,h H h wf (h) comp(h,caller,label) (I C (w, H) I C (w,h)) 12

15 This macro updates the history and class attributes non-deterministically with values satisfying the invariant, extending the history in a wellformed manner. Although output from this is allowed, the current method invocation may not be terminated. It follows immediately from this definition that the following Hoare triple holds: {I C (w, H)}release {I C (w, H)}. Also note that with respect to Hoare reasoning, two subsequent interleave statements, as well as two release statements, may be replaced by one. One could model the parallel execution of the environment by inserting interleave before each Creol statement, however, for simpler partial correctness it suffices to insert interleave before each statement accessing H. An interleave preceding a release may be omitted. The encoding. Asynchronous method calls give rise to events recorded in H: l!o.m(e) interleave; l := some l incr((h/this ).label l ); H := H this l o.m(e) Local synchronous calls are performed directly by this object, the history variable remains unaltered: m(e;y) = m(e;y) Reply statements block the object s internal activity. Therefore, input to the object may occur but output from the object is not allowed. In the translation of reply statements, interleave captures the desired effect on H by other objects. l?(y) interleave; while comp(h, this, l) do interleave od; y := find(h,this,l,comp).par In contrast, processor release points allow output from this object, except for the completion message of the current method invocation. Therefore, await statements are modeled by means of the release macro: await wait release await φ while φ do release od await l? release; while comp(h, this, l) do release od Since the recording of an event from o to o in H is generated by o, there is a non-deterministic (finite) delay before the event is accessible by o, which explains the initial release statement for await l? statements. Object generation is modeled so that each new object is given a unique identity, using the creator s identity combined with a local counter initialized to 0. v := new C(e) obcnt := obcnt + 1;v := id(this,obcnt) where obcnt is a mythical attribute of each object. Here the ob function and the obcnt attribute are available for reasoning, but not for programming. Uniqueness is guaranteed by the axiom ob(o,c) = ob(o,c ) o = o c = c. This formalization of object creation may be considered low level, revealing the parent object (creator) as well as a total order of all objects 13

16 generated by a given parent, reflecting time. However, this information might be considered relevant to reasoning (and possibly also programming). The remaining CreolK statements are translated directly into CreolB, as follows: skip skip x := e x := e ( S ) ( S ) while φ do S od while φ do S od if φ then S 1 else S 2 fi if φ then S 1 else S 2 fi S 1 S 2 S 1 S 2 where x is a list of disjoint variables to which there is write access. With respect to this simple translation of, the running interpret for Creol is included in this semantics since branches beginning with satisfied guards (or without a leading guard) are given priority over the others branches in Creol. Simplifications for partial correctness. When we limit ourselves to partial correctness, we may assume termination. This means that we may reinterpret reply and await as follows: l?(y) H := some h H h wf (h) h/out this = H/OUT this comp(h,this,l); y := find(h,this,l,comp).par await l? w, H := some w,h RelReq(w,h) comp(h,this,l) await φ if φ then skip else w, H := some w,h RelReq(w,h) φ w w fi where RelReq(w,h) denotes the above restriction of the release statement, i.e. RelReq(w,h) H h wf (h) comp(h,caller,label) (I C (w, H) I C (w,h)). Preservation of wellformedness. Next we will prove that the proposed encoding preserves wellformedness of history sequences. Theorem 1 CreolB programs preserve the wellformedness property. Proof. The proof goes by induction over method bodies. Given a method m, we first consider preservation over the body of m. This means that preservation of wellformedness must proved for every statement in the language. This is trivially proved for statements not altering the content of H. In addition, interleave and release preserves wf (H) by definition, i.e. {wf (H)} interleave {wf (H)} and {wf (H)} release {wf (H)}. It remains to prove wellformedness for l!o.m(e), which is encoded as an interleave followed by updates on l and H. Since interleave preserves wellformedness, we only have to consider {wf (H)}l := some l incr((h/this ).label l ); H := H this l o.m(e) {wf (H)} This leads to the verification condition: wf (H) ( l.incr((h/this ).label l ) ((wf (H) H H this l o.m(e) )l l ) 14

17 Assuming l fresh, this gives us: wf (H) incr((h/this ).label l wf (H this l o.m(e)) which follows directly from the definition of wellformed histories. By this we have proved {wf (H)}body {wf (H)} for all possible method bodies, and are left with sending of completion messages. Using the assumptions of (1), we first prove {init(h/(this.m), caller, label) comp(h, caller, label)} body {init(h/(this.m), caller, label) comp(h, caller, label)} Since there is read-only access to caller, label and this and the method name is constant, it suffices to show preservation of the predicate over interleave and release. The first follows from constance of H/OUT this during interleave, and the last follows from the assumption comp(h, caller, label) in release. The desired conclusion {wf (H)} H := H caller label this.m(y) {wf (H)} then follows by conjunction and backward construction. This concludes the proof that the encoding preserves wellformedness. 5.2 Parallel Composition For an object o of a class C, the invariant in a quiescent state may be defined in terms of the invariant I C. We recall from Section 4 that for a local history H, the invariant must hold for appropriate values of class attributes: I o:c (H) w (I C (w, H)) this o When composing two local histories, the amount of non-determinism in an object when seen in isolation is reduced, because two objects will synchronize on common communication events when composed. This is expressed trough projection on the histories. An invariant for the composed objects may consequently be derived from the invariants for o and o by conjunction: I o:c o :C (H) = I o:c(h/o) I o :C (H/o ) Since local histories are required to be projections of the composed history, the semantics of CreolB leads to many non-composable histories and is therefore not optimal for executing objects. For partial correctness reasoning however, the proposed semantics suffices. Composition may be generalized to sets of objects. Let O = {o 1 : C 1,...,o n : C n } and O = {o 1 : C 1,...,o m : C m } be object sets such that O O = and assume that the invariants I O and I O for O and O hold. The sets O and O may then be composed if all objects in the sets synchronize on shared communication events as described above. Let O denote parallel execution of the objects in O. The invariant of the composed system becomes: I O O (H) = I O (H/O) I O (H/O ) In general, for any system of objects O, the invariant I O (H) will hold in all global states where all the objects in O are quiescent, which is captured by the global invariant. In particular, the final state of a terminating system is quiescent. 15

18 6 Proof Rules for CreolK In this section we will construct reasoning rules for CreolK, based on the sequential sublanguage, CreolB. The construction is done by left construction over the encoding of CreolK in CreolB given in the last section, to achieve weakest liberal preconditions (wlp) [18] for the CreolK sentences outside CreolB. In the last part of this section we will derive some theorems which may be helpful both for the intuitive understanding of the proof system and for practical applications. 6.1 Proof rules for CreolB The weakest liberal precondition for non-deterministic assignment is: wlp(y := some x P,Q) x (P Q y x ) assuming x is disjoint from FV [Q] {y}. This side condition may easily be satisfied, since variable names in some expressions may be renamed by means of fresh variables. The rule for local synchronous call m(e;v) with static binding is standard [22] {P }body m(x,y) {Q} {P x e }m(e;v) {Qx,y e,v } This rule assumes no overlap between variables in P and Q and variables local to the current method body. The body of m is defined to be body m(x,y), where x and y are the lists of formal in- and out-parameters, respectively. The declaration of the body is found by static binding. Names of formal parameters may be renamed by fresh variables. The remaining reasoning rules for CreolB are standard and are included in Appendix B. CreolB has object references, but no dot notation for class attributes, thus Hoare reasoning about pointers can be done according to standard rules [8, 33]. The rules for non-deterministic assignment and local procedure calls maintain the soundness and relative completeness of the proof system. 6.2 Weakest Liberal Preconditions First we will construct weakest liberal preconditions for the invocation and completion sentences in CreolK. Then we will introduce weakest liberal preconditions for possible release points. Invocations. In CreolB, the sentence l!o.m(e) is encoded as an assignment to the history sequence. This sentence is translated into the model as: l!o.m(e) H := some h H h wf (h) h/out this = H/OUT this ; l := some l incr((h/this ).label l ); H := H this l o.m(e) The weakest liberal precondition, wlp(l!o.m(e), Q), for this sentence relative to a given postcondition Q then becomes wlp(l!o.m(e),q) l,h H h wf (h) h/out this = H/OUT this incr((h/this ).label l ) (Q H h this l o.m(e) )l l This precondition takes into account a non-deterministic update on H, restricted by interleave, immediately before the statement. 16

19 Reply. By left construction over the model of l?(y), the weakest liberal precondition for this language construction becomes: wlp(l?(y),q) h H h wf (h) h/out this = H/OUT this comp(h,this,l) Q H,y h,find(h,this,l,comp).par The interleave is captured by the condition as a non-deterministic extension of H, leaving H/OUT this unaltered. Release points. The await wait sentence is modeled by a release, which is a simultaneous assignment of w and h to w and H respectively, such that the following condition holds: RelReq(w,h) H h wf (h) comp(h,caller,label) (I(w, H) I(w,h)) The weakest precondition to await wait then becomes: wlp(await wait,q) w,h RelReq(w,h) Q w,h w,h Weakest preconditions to completion guards follows the same pattern and in addition we may assume the existence of completion messages wlp(await l?,q) w,h RelReq(w,h) comp(h,this,l) Q w,h w,h At last we consider boolean await statements. If the guard is true when program control enters such sentences, execution is not suspended, which is reflected in the precondition: wlp(await φ,q) if φ then Q else w,h RelReq(w,h) φ w w Qw,H w,h fi Object generation. wlp(v := new C(e),Q) Q v,obcnt ob(this,obcnt+1),obcnt+1 where obcnt is a mythical attribute used for reasoning purposes, as explained in the above modeling. This way, we have established a reasoning system in terms of the weakest liberal preconditions for the language constructions introduced in CreolK. This can be used directly to verify the preservation of a class invariant over method bodies, using the following equality given by Dijkstra [18]: wlp(s 1 ;S 2,Q) wlp(s 1,wlp(S 2,Q)) Given a method m with formal in-parameters x, we then have to prove (I C (w, H)) z wf (H caller label this.m(z)) x = (find(h,caller,label,init)).par) wlp(w m = Initvalues;body; H := H caller label this.m(y),i C (w, H)) In practice however, this brute force approach to verification is often more complicated than what we need in order to establish our goal, namely a proof of the correctness of the invariant over method bodies. To see this, we note that all the definitions of weakest liberal preconditions can be translated into Hoare triples as: {wlp(s, Q)} S {Q}. Together with the rule of consequence this can be used for reasoning purposes by noting that proving {P }S {Q} is the same as proving P wlp(s,q). With this machinery we are free to use both wlp-reasoning and reasoning in terms of Hoare rules in the same proof. We will in the following subsection explore some properties about the proposed reasoning system. 17