3 a Semantic Model

Original citation: Liu, Z. (1989) A semantic model for UNITY. University of Warwick. Department of Computer Science. (Department of Computer Science Research Report). (Unpublished) CS-RR-144

Permanent WRAP url: http://wrap.warwick.ac.uk/60839

Copyright and reuse: The Warwick Research Archive Portal (WRAP) makes this work by researchers of the University of Warwick available open access under the following conditions. Copyright © and all moral rights to the version of the paper presented here belong to the individual author(s) and/or other copyright owners. To the extent reasonable and practicable the material made available in WRAP has been checked for eligibility before being made available.

Copies of full items can be used for personal research or study, educational, or not-for- profit purposes without prior permission or charge. Provided that the authors, title and full bibliographic details are credited, a hyperlink and/or URL is given for the original metadata page and the content is not changed in any way.

A note on versions: The version presented in WRAP is the published version or, version of record, and may be cited as it appears here.For more information, please contact the WRAP Team at: [email protected]

http://wrap.warwick.ac.uk/ A Semantic Model For UNITY

Zhiming Liu University of Warwick

Abstract

This paper develops a semantic model for UNITY that re¯ects its particular aspects, such as nondeterminism, absence of control ¯ow etc.. The proposed model is a kind of state-transition system within which observations and actions are the basic semantic objects. An alternative semantics for UNITY programs based on different fairness conditions is also de®ned using this model. Specially, the fairness condition assumed in [CM88] is de®ned and theUNITY logicbased on it is modelled to show how the safety and liveness (progress) properties can be represented. This model is beeing used as the basis for developing some formal techniques for fault-tolerance within a UNITY framework.

Address for correspondence: Department of Computer Science, University of Warwick, Coventry CV4 7AL. This work was supported by research grant GR/D 11521 from the Science and Engineering Research Council.

1 1 Introduction

Much of program development consists of re®ning speci®cations by adding detail. Given a problem speci®cation, we begin by proposing a general solution strategy. Usually the strategy is broad, admitting many solutions. Next we give a speci®- cation of the solution strategy and prove that this strategy (as speci®ed) solves the problem (as speci®ed). When we consider a speci®c set of target architectures, we may choose to narrow the solution strategy, which means re®ning the speci®cation further. At each stage of re®nement, the programmer is obliged to prove that the speci®cation proposed indeed re®nes a speci®cation proposed at earlier step. The construction of a program is begun only after the program has been speci®ed in extensive detail. A framework has been developed in UNITY [CM88] to meet all these purposes. UNITY can be taken as a theory ± a computational model and an associated proof system in which programs can be viewed as Unbounded Nondeterministic Iterative Transformations. It based on the thesis that the unity of the programming task transcends differences between the architectures on which programs can be executed and the application domains from which problems are drawn. The goal of the UNITY work is to show how programs can be developed systematically for a variety of architectures and applications. Programs can be developed for different architectures, e.g. the von Neuman- n architecture, synchronous shared-memory multiprocessors, and asynchronous shared-memory multiprocessors, through a series of re®nements by specifying program execution with as little detail as possible. Specifying little about program execution means that the programs may be nondeterministic. Different runs of the same program may execute statements in different orders, consume different amounts of resources, and even produce different results. Nondeterminism can be employed to derive simple programs, where simplicity is achieved by avoiding unnecessary determinism; such programs can be optimized by limiting the nondeterminism, i.e. by disallowing executions unsuitable for a given architecture. A UNITY program consists of a declaration of variables, a speci®cation of their initial values, and a set of multiple-assignments. A program execution starts from any state satisfying the initial condition and goes on forever; in each step of execution some assignment statement is selected nondeterministically and executed. Nondeterministic selection is constrained by the following fairness rule: every statement is selected in®nitely often. A UNITY program describes

2 what should be done in the sense that it speci®es the initial state and the state transformations (i.e. the assignments). A UNITY program does not specify precisely when an assignment should be executed ± the only restriction is the rather weak fairness condition. Neither does a UNITY program specify where (e.g. on which processor in a multiprocessor system ) an assignment is to be executed, how assignments are to be executed or how an implementation may halt a program execution. Thus, UNITY seperates concerns between what on the one hand, and when, where and how on the other. The what is speci®ed in a program, whereas the when ,where, and how are speci®ed in a mapping. The computaional model on which UNITY is based on state-transition systems [Pnu81, MP83, LT87]. A programming logic and a proof system associated with the model developed in UNITY allow the proof to be seperated from the program text, and developed and studied a proof in its own right. The speci®cations, re®nement of speci®cations, proof system and mapping programs to architectures are all based on a semantic model that is assumed to exist in UNITY work. This paper develops such a semantic model for UNITY that re¯ects aspects of UNITY such as nondeterminism, absence of control ¯ow, etc.. The semantic model is intended to model the UNITY programming logic and proof system, and to support the UNITY speci®cation. This model is a kind of state-transition systems within which observations and actions of assignments are the basic semantic objects. With this model, it is shown that how the different fairness conditions, termination of a program execution can be de®ned and how the safety and liveness (progress) properties can be represented.

2 Notes on UNITY

This section presents a subset of the UNITY notation that needed for the development of the semantic model.

Primitive Commands: The primitive commands are conditional multiple assignments of the fol-

lowing form:

x x e e b m

1,. . . , := 11,. . . , 1m if 1

e e b

21,..., 2m if 2 . .

e e b

nm n

n1,. . . , if , b where, all the e's are expressions and the 's are boolean expressions. Thus, a multiple assignment consists of variable list on the left side and expression lists with corresponding boolean expressions on the right side. If all component simple-expression lists (without boolean expressions) whose

associated boolean expressions are tr ue are equal in value, any one of them can be choosen for assignment; if they are not equal in value, then the

assignment results in a failure; if no boolean expression is tr ue, the variable values are left unchanged.

Statements: In [CM88], only primitive commands are UNITY statements. For de®ning different fairness conditions and making the semantic model mathematically

elegant, the statements of the language are de®ned as follows:

S (S []S ) primitive commands are statements, and if S1 and 2 are statements, 1 2

is a statement. The following equivalences hold:

S []S ) (S []S ) (S []S ) S ( 1 2 2 1 and .

Programs: An UNITY program consists of a program-name, a declare-section which declares the types of the program variables, initially-section which de®nes

the initial values of some variables in this program and an assign-section

S [] []S

which is a statement list, 1 . . . n . (See [CM88] for more details). Since the types of variables are going to be ignored in the semantic model, the declare-section here is not considered any further here. The initially- section is a set of equations which is proper in the sense that it can be used to determine the values of some variables named in the program Here, the initially-section can be generally taken as a predicate about variables in the

program. Therefore, a UNITY program can be abstractly denoted as

= (P r L) P ,

where, P r is a set of predicates over the initial values of the variables

L P r

named in P , and is the assign-section of the program, is in fact a set

= e e of equations of the form x , where is an expression.

4 In UNITY, there are two different kinds of compositions of programs. The union of two programs is obtained by appending their codes together. Unlike union, superposition describes modi®cations of a given program by adding new variables and assignments, but not altering existing assignments. Thus, superposition preserves all the properties of the original program. For detailed de®nitions of the two kinds of compositions, see Section 4

3 A Semantic Model

3.1 An Informal Overview

As seen in Section 2, an UNITY program contains a statement list. Let S be a

statement in such a program. In an execution of S , let each of its variables be represented by its observed value, which is the sequence of values assigned to the variable. Thus, each multiple assignment to a set of variables appends an element to the previous observed value of each variable in the set. An execution

of S can then be described in terms of the observed values of its variables, and it is suf®cient to record the observed values of its variables before and after the execution of each primitive command.

An observation of a statement S in a program is the set of observed values

of the variables of the program taken at the same instant of time. If the empty

x x y y sequence is the initial observed value of the variables 1, 2, 1 and 2 for an

execution of the statement

x = []y y =

x1 2 : 1 2 1 2 : 3 4, y then the sequence of the observed values of the x's and 's would be

Observations

x1 1

x2 2

x = if x1 2 : 1 2 is selected to be executed, or

Observations

1 3

y2 4

y = if y1 2 : 3 4 is selected to be executed. Thus, a statement in a program can be taken as an action, each execution of which transforms one observation into another; primitive commands can be taken as atomic actions. Each element in an observed value is either taken from the value space of the programming variables or is a distinguished value representing a particular result

of the execution of a statement. For example, execution of the statement

= []y = x +

x : 3 : 1

x +

will result in y the value of the expression 1 only when that is de®ned and

= x +

y : 1 is selected to be executed. But if before executing this statement the

y y = x + observed value of x is , the value of is not de®ned if : 1 is selected

to be executed, and the execution fails. The failure induces the in all variables. Therefore, the execution of the statement will produce

Observations

y v v

v x y y = x + if and are the initial observed values of and respectively and : 1 is selected to be executed.

A behaviour of an UNITY program P is an in®nite sequence of observations over its variables. The ®rst observation is determined by the initially-section of

P and each of the rest is produced from its predecessor by an execution of a

statement selected from the statement list of P . A behaviour of a program is ®nite if after some observation in the sequence all the values of the variables appended in the observations keep unchanged. Properties of observations can be found in [JG88, JG89] in more details.

6 3.2 Observations Obsrvations instead of states is used as the basic semantic objects. This makes it

easy to de®ne atomic actions and composed actions in mathematical way. Let X

be a set of program variables with value space V equipped with an equality relation

`=' which is the minimum re¯exive relation on V . We shall initially ignore the

types of the variables, but it is relatively easy to extend the concepts in this paper

to include types. Let V be the set of all the ®nite sequences (including the empty

V V S top

sequence ) over . In addition to , we assume a set, , of distinguished

V S top values (S top = é): after a variable has taken a value from , it can be only

assigned a value in S top. Let

o n

y a +

= s djs V d S top

V ,

+ S top where S top is the set of all ®nite sequences over without including the

empty sequence .

Then the set of observed values is de®ned as

W = V V

S top U

We also denote the set of all the one-element sequences over V as .

S S

Some functions and predicates on W are needed. In what follows, , 1 and W S2 are sequences in .

the empty sequence;

S =

#S the length of (# 0 );

[i] S i S

S the ith element of ( 0 # );

S S S

S1 2 1 is a pre®x of 2;

S S S

S1 2 1 is a proper pre®x of 2;

S S S

S1 2 the catenation of 1 and 2;

v v V S

S appending the element in to the end of ;

(S ) S S

f ir st the ®rst element of if is not empty;

(S ) S S l ast the last element of if is not empty;

(S ) l ast(S ) S = cur r ent the one-element sequence consisting of if ,

and otherwise;

(k S ) S k

r est the sequence obtained from by removing the ®rst ele-

ments ifk # , and otherwise;

(S k ) S k

r est the sequence obtained from by removing the last elements

if k # , and otherwise;

(S S ) r est( S S ) S S S S S

r est 1 2 : # 1 2 if 1 2 or 2 1, and 2 otherwise;

(S ) S S

r ang e the range of , i.e. the set of the elements occurring in ;

(k S ) tr ue r ang e(r est(k S )) fS [k ]g f ixed is iff is or é. With the informal description given in the previous subsection, an observation

on a set of variables X can be formally de®ned as a function as follows.

O b X W

De®nition 3.1 An observation on X is a function : satisfying

x X (l ast(O b(x)) = ) y X (l ast(O b(y )) = )

f(x O b(x))jx X g S top where O b can be denoted as the set of pairs and .

In the following, some of the functions and predicates over W given above

X OB O b O b are extended to the set of all the observations on denoted as X , , are

observations and k is an natural number.

O b O b x X O b (x) O b (x)

iff for each , 1 ;

O b O b O b O b x X O b (x) O b (x)

1 iff 1 and there is some , 1 ;

f ixed(k O b) x X f ixed(k O b(x))

;

cur r ent(O b)(x) = cur r ent(O b(x)) x X

for all ;

r est(k O b)(x) = r est(k O b(x)) x X

for all ;

a a

O b (x) = O b O b (x) O b (x) x X 1 1 for all .

3.3 Actions

X OB

An action on a set of variables is a relation on the set of observations X ±

(s t)

that is, a set of pairs of observations. If is an action, then means that

s t executing starting in will get to the observation . Thus a statement in a UNITY program can be de®ned as an action on the program variables, which speci®es the transformation de®ned by the statement.

De®nition 3.2 An action on X , , is a relation on the set of all the observations

X s OB t OB [(s t) ] X on such that X and the following conditions

are satis®ed:

s t) s t

1. ( ;

s t) (cur r ent(s) cur r ent(s) r est(s t))

2. ( .

x X [(s t) r ang e(cur r ent(s(x))) = fg t(x) = s(x) ] 3. .

Condition 1 means that executing an action can only extend the observed values of its variables but cannot change any observed value which has already occurred, Condition 2 says that the transformation made by an action only depends on the current values of the observation with which the execution of the action started and Condition 3 implies that an action cannot have any futher effect on a variable

after it has taken the value .

X v W s

For an observation s on and , is the function obtained from

x x

(x) = s(y )) (x) = v ) y X (y = x s (s

s such that . An action

v v

x (s t)

modi®es a variable if there is a pair of observations in such that

y X (l ast(t(y )) S top) s(x) = t(x) x

and ; essentially modi®es if there

s t) l ast(s(x)) = l ast(t(x)) = S top x

exists ( such that ; does not read if

x x

s t) v x s t

for any ( and any observed value of such that that and are valid

v v

x x

) t s

observations with respect to De®nition 3.1, ( ; does not (essentially)

v v

access x if does not (essentially) modify or read .

Intuitively, x is modi®ed by if it takes value by an assignment in , is read

x = y + if f al se

by if its value is used by an assignment in . For examples, : 1

x = x x x does not modify x; : modi®es but does not essentially modify .

Operations on actions:

Y X s t X t

For a set X of variables and a subset of , let and be actions on ,

t y Y (t (y ) = s(y )) x

be the function obtained from s and such that

(x) = t(x)) (X Y )(t

. In the following, Act denotes the set of all the actions s

on X .

Act Act Act

Union: : ,

f(s t)j(s t) or (s t) g

= .

Act Act Act

Composition: : ,

= f(s t)j t [(s t ) ] [(t t) ]g 1 1 1 .

Act Act

Closure: *: ,

n n+ n

1 0

= f(s t)j n [(s t) ]g = = f(s s)js 0 , where and

is an observationg .

k Act Act Act

Augmentation: : ,

X X

for actions and , let 1 and 2 be the sets of variables that are not

modi®ed by and respectively, X

X1 2

(s t) k (s t (s t x X t(x) = )

if ) and , or for any ,

s s

s(x) s t ) x X (l ast(t (x)) = )

if there is a ( 1 such that 1 , or

s t ) x X (l ast(t (x)) = )

there is a ( 2 such that 2 , or there are

s t ) (s t ) (t (y ) = t (y )) y X

( 1 and 2 such that 1 2 for some which

is modi®ed by both and .

= if f al sek x = x + x = x +

Intuitively, x : 0 : 1 is equivalent to : 1 and

= x k x = x +

x : : 1 produces in the semantic model. X De®nition 3.3 An action on , is called atomic if it satis®es the following

conditions:

s t ) (s t ) t = t

1. (deterministic): ( 1 , 2 1 2;

s t) x X [(t(x) = s(x)) v U (t(x) =

2. (one-stepping): (

(x) v )]

s .

= s OB ( x X ( s(x)

Theorem 3.1 For actions and , iff X 0 #

) t OB ((s t) (s t)

1 X )).

= x X ( s(x) )[(s t)

Proof: It is trivial to show that if , 0 # 1

s t) ]

( .

= s OB ( x X ( s(x) )

To prove that only if , X 0 # 1

t OB ((s t) (s t) )) X = fxg

X ; we assume that without loss of

s t) s (s t) s

generality. Let ( , if # 1, we have already got . If # 1, from

cur r ent(s) cur r ent(s) r est(s t))

Condition 2 in De®nition 3.2, we have ( ,

cur r ent(s) cur r ent(s) r est(s t)) cur r ent(s(x))

and thus ( because # 1.

s t)

Again from Condition 2 in De®nition 3.2, ( . 2

Theorem 3.2 The set of all atomic actions is closed under the augmentation, that

is, if and are atomic actions, then so is .

X X

Proof: Let and be atomic actions, 1 and 2 be the sets of variables that

are not modi®ed by and respectively. It is obvious that is one-stepping.

Therefore, it is suf®cient to show that is deterministic.

s t ) (s t ) k x(t (x) = s(x) ) x(l ast(s(x)) =

Let ( 1 2 , if 1 , then

) t[(s t) x(l ast(t(x)) = )] t[(s t) x(l ast(t(x)) = )]

s t) (s t ) y

or there are ( , and which is modi®ed by both and , such that

t(y ) = t (y )

( . Since and are atomic, it is easy to check that for each case listed

a a

x(t (x) = s(x) ) t = t x(t (x) = s(x) )

above, 2 , that is 1 2. Similarly,if 1 ,

= t x l ast(t (x)) = x l ast(t (x)) =

then t1 2. If for any , 1 , then for any , 2 and

X X X

1 X1 2 2

(s t (s t ) (s t ) (s t )

) . Since and

(X ) s(X ) s(X ) s(X )

1s 1 2 1 1 2 2 2

X X X

X1 1 2 2

) = (s t ) ) = (s t ) s t (s t t = t

are atomic, ( and . Hence, .

(X ) s(X ) s(X ) s(X )

1s 1 2 1 1 2 2 2 1 2 2

In the UNITY framework, augmentations are applied only to atomic actions.

De®nition 3.4 The class of generated actions is de®ned recursively as follows:

1. Atomic actions are generated actions;

2. If and are generated actions, then is a generated action;

3. If and are generated actions, then is a generated action;

k 4. If and are generated actions, then is a generated action; 5. Generated actions can be obtained only by applying these rules ®nitely many times.

De®nition 3.5 An action, , is a program action if it can be decomposed into the union of a set of atomic actions.

Theorem 3.3 The set of all program actions on X is closed under the union, i.e.

if and are program actions, is also a program action.

Proof: Trivial. 2

3.4 Executions

Π X R De®nition 3.6 Let X be a set of variables, be a set of actions on and 0 be

an observation on X ; then an in®nite sequence of observations,

E R R R

= 0 1 . . . i . . .,

Π i Π

is an execution of with R0, if for each 0, there exists an action , such

(R R ) E = (R )

i+ i

that i 1 , and this is denoted as .

(R Π) Π R

We use E x 0 to denote the set of all executions of with 0, and

(Π) Π EX to denote the set of all the executions of . Later, we will de®ne an UNITY program as a set of program actions. The properties of the program are

expressed as assertions over the set of executions. Also, we can treat an execution,

E = (R )

i , as a function from the set of natural numbers to the set of observations

OB i R = E (i) (E (i) E (i + )) Π i X such that for all 0, and 1 for some . We use both sequences and functions to represent executions in this paper. Π

De®nition 3.7 Let be a set of actions on X and

E R R R

= 0 1 . . . i . . .

E Π

is an execution of Π with R0, is called a ®nite execution of , if there exist

n m i n f ixed(m R ) = tr ue n

0 and 0 such that for any , i , and if is E the least number for which such an m can be found, the ®nite execution is

represented as

E R R

= 0 . . . n .

Π Π

De®nition 3.8 An execution of is said to be fair, if for any i 0 and ,

k i (R R )

k +

there is some such that k 1 .

(R Π) Π R

We use F ex 0 to denote the set of all fair executions of with 0, and

(Π) Π FEX to denote the set of all the fair executions of . Note that if a statement is de®ned as an action while a primitive command is de®ned as an atomic action, the de®nition of fairness seems to be weaker than that given in [CM88] in the following sense: a UNITY program in [CM88] can Π be de®ned as a set of atomic actions Π, and to say that an execution E of

is fair just means that E could be obtained by executing each atomic action in

12 Π in®nitely many times, but possibly also if certain atomic actions in Π were executed only ®nitely many times. On the other hand, the fairness condition given here is abstract, and is suf®cient for reasoning about programs and justifying implementations of programs (see Section 4). There can be many different sets

Π that give the same same set of executions. For example, replacing two actions

and by the single action does not change the set of executions but may change the set of fair executions. Thus, there can be many equivalent ways to write essentially the same program. In [MP83] this particular form of fairness is called justice [GP89]. Some

other alternative forms of fairness [Fra86] can be also be de®ned. Specially, let

Π Π E Π Π

Π = 1 2. An execution of is said to be fair with respect to 1, if for each

Π k i (E (k ) E (k + ))

i 0 and each action 1, there exists such that 1 .

Π i

E is said to bounded with respect to 1, if there exists 0 such that for any

i (E (k ) E (k + )) Π k , 1 for some 2. Such forms of fairness can be used to de®ne the sumption that faults cannot occur in®nitely often when dealing with fault-tolerance [Liu89]. The logic for speci®cation and proof of correctness of programs is of course based on speci®c fairness. The UNITY logic is based on justice. When we deal with the semantics of programming languages, we are usually interested only in the executions of sets of generated actions. For UNITY, we concentrate on the executions of sets of program actions.

4 The Semantics of the UNITY Notations

The semantics of expressions: E xpr

Let X be the set of the variables used in a program, be the set of all the V expressions over X and , then the semantic function for the expressions is

de®ned as:

E xpr (F unc(V S top) V S top)

E : ,

(S ) S

where F unc is the set of all the functions with ®nite arguments over

e(x x ) x x n

, and for each expression 1 . . . n with 1,..., occurring within it,

E (e(x x )) e

1 . . . n is determined by the operations used in and satis®es the following strictness condition:

e(a a ) = a i 1 . . . n , if some = .

where there is no confusion, we also use the expression e to represent the

(e) value of E .

The semantics of the UNITY Statements: P r og act Let S tatement denote the set of all the UNITY statements and denote the set of all the program actions, the semantic function for statements

is de®ned recursively as

S tatement P r og act S : :

1. Basis: For a primitive command p,

x x e e b m

1,. . . , m := 11,. . . , 1 if 1

e e b

21,..., 2m if 2 .

e e b

nm n

n1,. . . , if ,

(p) (s t)

S consists of the pairs satisfying :

x X (l ast(x) = t(x) = s(x) )

(a) ;

i n(b (cur r ent(s)) = f al se) t = s

(b) i ;

k b (cur r ent(s)) = tr ue s(y ) =

y e i m x X (t(x) =

for some named in k i for some , then

(x) )

s ;

i j m i = j x = x j

(d) if there are such that i and there is

k n b (cur r ent(s)) = tr ue e = e

k i k j

a such that k , but , then

x X (t(x) = s(x) )

;

k l n b (cur r ent(s)) = b (cur r ent(s)) = l

(e) if there are such that k

tr ue i m e = e x li

, but there is an such that k i , then

(t(x) = s(x) )

X ; otherwise

k n b (cur r ent(s)) = tr ue i

(f) if there is a such that k , then

m(t(x ) = s(x ) e ) t(x) = s(x) x

i k i

i and for any that is different x

from each i .

(S []S ) = S (S ) S (S ) 2. Recursion: S 1 2 1 2 .

14 The Semantics of Statement Lists:

A statement list is of the form as:

L = S [] []S

1 . . . n .

The semantics of L is de®ned as follows:

L(L) = fS (S ) S (S )g

1 . . . n .

So the semantics of a statement list is the set of the program actions determined by the statements of the list. It is reasonable to semantically

treat staements and statement lists at different levels because of the fairness L

conditions. Note that for statement lists, L1 and 2,

(L []L ) = L(L ) L(L ) L 1 2 1 2 .

It is not very essencial for us to consider the empty statement list N U LL, i.e.

(N U LL) a list without any statement. If we have to consider it, just let L = é.

Now we can de®ne the set of behaviours of a statement list, L, as the set of

(L) BEH (L)

executions of L , and denote it as , thus,

(L) = EX (L(L)) BEH .

In the same way, we can de®ne the set of fair behaviours of a statement list

FBEH(L) L, and denote it as .

The Semantics of UNITY Programs: We de®ne the semantics of an UNITY program as a set of behaviours of the statement list contained within it , in which each behaviour satis®es the initial conditions de®ned in the initially-section of the program and some

fairness conditions.

= (P r L) L F B E H (L)

For a UNITY program P , we say a behaviour of ,

x X ( F ( ) )

satis®es the initial condition P r , if for all # 0 1 and

[F ( )] = tr ue F S atP r F P r

P r 0 , and denotes that satis®es . Here, the

[F ( )] = tr ue meaning of P r 0 is just the same as that in ®rst order logic.

15 Now we can de®ne alternative semantics for UNITY programs based on dif-

ferent fairness conditions.

= (P r L)

De®nition 4.1 Let P be an UNITY program, L

1. The loose semantics of P is de®ned as the set of the behaviours of that P

satis®es the initial condition P r , of , i.e.

(P ) = fF jF B E H (L) F S atP r g

BEH ; L

2. The fair semantics of P is de®ned as the set of of the fair behaviours of P

that satis®es the initial condition P r of , i.e.

(P ) = fF jF F B E H (L) F S atP r g

FBEH ;

= f al se P = (P r L)

Note that if P r in , then

(P ) = FBEH(P )

BEH = é. L The fair semantics of P can be implemented by executing each statement in

in®nitely many times. We can also de®ne some other alternative semantics for

= (P r L []L ) F

UNITY programs. Specially, let P 1 2 . We say that a behaviour, ,

= L []L L F L(L ) F

of L 1 2 is fair with respect to 1, if is fair with respect to 1 . is

F L(L ) F

bounded with respect to L1, if is bounded with respect to 1 . is bounded

F L

with respect to L1 means that can be obtained by executing 1 only ®nite times. =

Now let us look into composition and superposition of programs. If P1

(P r ) P = (P r L ) P P

1 L1 and 2 2 2 are programs, the union of 1 and 2 is written as

[]P B

P1 2. We use to denote any one of the semantic functions based on different FBEH

fairness conditions, such as BEH and etc, then we de®ne

(P []P ) = B (P r P r L []L ) B 1 2 1 2 1 2 . Note this de®nition is consistent with the assumption that there are no inconsis-

tencies in the de®nitions of variables.

= (P r L) s P r

For a program P , and a primitive command in ,if is a primitive

s s

= (P r L ) Q P

command, let P represent the program that is obtained from by

r r

P r P = (P r L)

replacing s in by . We can de®ne an augmentation of a program

with P r and a primitive command as follows:

(P s P r r ) = (P r P r L )

A ,

skr

P r

where, s is a primitive command in , is a primitive command which does not

P r

modify any variable named in P and is a prdicate about the initial values P of the variables named in r . The program in the above equation is called the underlying program.

Now we have the semantics of an augmentation of a program as

(A(P s P r r )) = B ((P r P r L ))

B ,

skr

i.e. relacing the atomic action determined by s by the atomic action determined

k r by s . After modelling the UNITY programming logic, it is easy to prove the Union Theorem in [CM88], but the Superposition Theorem in [CM88] is required to be restated in our framework as: Every property of the underlying program is a property of the augmentation if no failure is introduced by the superposed variables.

5 Modelling the UNITY Programming Logic

This section shows that within the semantic model given in this paper, the UNITY programming logic can be modelled and thus safety and progress properties of a program can be described. In this section, all predicates used in the logic are about

observations on speci®ed sets of variables. For each variable x withvalue space

V x W = V V x

x , a sequence vriable is introduced whose value space is . A

x x

p OB X x x X p

predicate over X names only variables in or some for . Let be a

OB O b OB O b j= p p[O b] tr ue X

predicate over X and be an observation in , iff is ,

[O b] x X l ast(O b(x))

where p is obtained by replacing each occurrence of by

O b(x) and each occurrence of x by .

Most properties of a UNITY program are expressed using assertions of the form

pgS fq g S

f , where is universally or existentially quanti®ed over the statements

pgS fq g

(here statements are assignment statements) of the program. f denotes p

that an execution of statement S in any state (observation) that satis®es predicate S results in a state (observation) that satis®es predicate q ,if execution of terminates. Properties that hold for all program observations during execution are de®ned using only universal quanti®cation. Properties that hold eventually are de®ned using existential quanti®cation as well.

17 Traditionally, a program property is regarded as either a safety or a progress property. Existential quanti®cation over program statements is essential in stating progress properties, whereas safety properties can be stated using only universal quanti®cations over statements (using the initial condition). For describing certain kinds of properties that should be considered with any program, the terms, unless, stable, invariant, ensures, leads-to and ®xed point, are introduced and theorems

about them are derived in UNITY. Therefore, the essential part of modelling this

pgS fq g

logic is modelling assertions of the form f .

pgS fq g

Since statements are de®ned as actions, f is de®ned as the triple

pgS (S )fq g

f . A general de®nition of the Hoare logic of actions is needed [Lam87].

X p q OB

Let be an action on , and be predicates over X ; the Hoare triple

pg fq g (s t) [(s j= p) (t j= q )]

f is de®ned to mean . In other words,

pg fq g p tr ue s

f asserts that if is in observation and executing in observation

t q tr ue t s can produce observation , then is in . It is easy to check that the usual rules for reasoning about Hoare triples [Hoa69] hold for triples of actions. Some

of these are listed as follows:

fpg ftr ueg

;

ff al seg fq g

;

fpg ff al seg p

;

fpg fq g fp g fq g fp p g fq q g fp p g fq q g

;

p p fpg fq g q q fp g fq g

if , and , then ;

fpg fq g fp g fq g fp p g fq q g fp p g k fq q g

if and , then and ;

= p q = q

note the special case when p and .

fq g fq g fq g fq g fq g fq g if , then and . Π Π For a given set of actions (program actions) , p unl ess q in is de®ned as

follows:

Π(fp q g fp q g)

p unl ess q .

tr ue Π q

Thus if p is at some point in an execution of and is not, in the next step

tr ue q tr ue p (i.e. after execution of an action) p remains or becomes . Hence, if holds at any point during an execution of Π, then either

q p

never holds and continues to hold forever, or

q p p holds eventually (it may holds initially when holds) and continues to

hold at least until q holds.

This can be formalized and easily proved as the following theorem.

unl ess q Π E Π i

Theorem 5.1 p in iff for each execution of and any 0,

p q )[E (i)] (p q )[E (i + )]

( 1 .

Π E Π i

Corollary 1 If p unl ess q in , then for any any execution of and 0,

p[E (i)]

j i (p q )[E (j )] ( p q )

: j :: i.e. holds forever

k i q [E (k )] ( q ) k

[ : :: i.e. holds eventually

i j k (p q )[E (j )] ( p q ) ] j

: :: i.e. until then holds . 2

The special cases of unl ess are stable and invariant. For a given set of actions

Π,

p p unl ess f al se

is stable

q q ) q

is invariant (initial condition is stable

p fpg fpg

We say that an action leaves stable if and only if holds. For

x X (l ast(ob(x)) = )

example, every action leaves stable. If leaves both

q p q p q

p and stable, then it leaves and stable as well; if both and leave

p p

q stable, then leaves stable; if does not modify the variables in , then

p x(l ast(ob(x)) = ) p x(l ast(ob(x)) = )

leaves both and stable;

p q p q

if leaves stable and leaves stable, then leaves stable and if no

k p q p variable can be modi®ed by both and , leaves stable. is stable in

Π iff each action in Π leaves p stable. The ensures relation (over predicates) is used to de®ne the most basic progress

properties of programs. For a given set of actions (program actions), Π, p ensur es

q is de®ned as follows:

(p unl ess q Π fp q g fq g ) p ensur es q : :: .

tr ue Π p tr ue q

Thus if p is at some point in an execution of , remains as long as

q tr ue

is f al se, and eventually becomes if the execution is fair. Hence we have

Π E Π i

Theorem 5.2 p ensur es q holds in iff for any fair execution of and 0,

[E (i)] j j i q [E (j )] k i k j p[E (k )]

p : :: : ::

ensur es

The leads-to ( ) relation over predicates is de®ned by and inference

q Π

rules [CM88]. In terms of action-executions, p holds in if for any fair

Π i

execution E of and 0,

[E (i)] j j i q [E (j )]

p : :: .

Π E Π

Finally, the ®xed point FP of is de®ned as : for any execution of and

i 0,

[E (i)] j j i cur r ent(E (i)) = cur r ent(E (j ))

FP : :: . i

Obviously, FP is reachable ( i.e. such an exists in the above equivalence ) for E E iff is an ®nite execution. It is straightforward (but tedious) to prove the validity in our framework of the rules of the UNITY proof system and the theorems about ensures, leads-to, stable, invariant and ®xed point. We leave these to the interested reader.

6 Conclusions and Discussions

The basic semantic objects of our approach are observed values of program variables and actions - relations over sets of observed values. The purpose of intro- ducing actions into the model is to formalize alternative fairness conditions so as to obtain alternative semantics for programs. The semantic model has been constructed for justifying the UNITY speci®cation and proof system. Obvious- ly, speci®cations and proof systems heavily depend upon the assumed fairness conditions. In fact, the semantic model established in this paper is quite language inde- pendent. It is easy to be extended to model conventional programming language constructs and architectures [JG88, JG89]. Therefore, this semantic model could

20 be suitable for justifying proofs of the correctness of mapping UNITY programs to alternative architectures. The proposed semantic model could also support the techiniques for developing

fault-tolerant systems that are presented in UNITY.And some concepts,such as ªan x action does not (effectively) modify a variable º, might be useful for describing properties of faulty actions, e.g to show that a faulty action does not (essentially)

modify a safe variable, e.g. a variable used for checkpointing. For programs

= (P r L ) P = (P r L ) P []P

P1 1 1 and 2 2 2 , we can de®ne for 1 2 the semantics that

L P is fair with respect to L1 and bounded with respect to 2. When taking 2 as the program which simulates the speci®ed hardware faults, some properties of its behaviour could be described. Furthermore, this semantics ®ts the sumption that faults can only occur ®nitely often. This model is beeing used as the basis for developing some techniques for fault-tolerance within the UNITY framework [Liu89]. Acknowledgment I wish to thank my supervisor, Prof. Mathai Joseph, for his constant encourage- ment, guidance, and his comments on earlier versions of this report as well. My thanks also go to my colleagues, A. Goswami and A.M. Lord, for the helpful discussion during this work.

References

[CM88] K.M. Chandy and J. Misra. Parallel Program Design: A Foundation. Addison-Wesley Publishing Company, 1988.

[Fra86] N. Francez. Fairness. Springer-Verlag, New York, 1986.

[GP89] R. Gerth and A. Pnueli. Rooting unity. In Proceedings of the 5th IEEE International Workshop on Software Speci®cation and Design, February 1989.

[Hoa69] C.A.R. Hoare. An axiomatic basis for computer programming. Com- munications of the ACM, 12(10):576±583, October 1969.

[JG88] M. Joseph and A. Goswami. What's `real' about real-time systems? In Proceedings of IEEE Real-time Systems Symposium, pages 78±85, Huntsville, Alabama, December 1988.

21 [JG89] M. Joseph and A. Goswami. Formal description of real-time systems: A review. Information and Software Technology, 31(2):67±75, March 1989.

[Lam87] L. Lamport. win and sin: Predicate transformers for concurrency. Tech- nical Report 17, Systems Research Center of Digital Equipment Corpo- ration in Palo Alto, California, May 1987.

[Liu89] Z. Liu. Modelling checkpointing and recovery within unity. Technical Report 145, Computer Science Department, University of Warwick, August 1989.

[LT87] N.A. Lynch and M.J. Tuttle. Hierarchical correctness proofs for distributed algorithms. In proceedings of 6th Annual ACM Symposium on Principles of Distributed Computing, Vancouver, British Columbia, Canda, 1987.

[MP83] Z. Manna and A. Pnueli. How to cook a temporal proof system for your pet language. In Proceedings of 10th Annual ACM Symposium on Principles of Programming Languages, Austin, Texas, 1983.

[Pnu81] A. Pnueli. The temporal semantics of concurrent programs. Theoretical Computer Science, 13:45±60, 1981.