Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: Data refinement of mixed specifications : a generalization of UNITY
CITATION PDF VIEWER THUMBNAILS PAGE IMAGE ZOOMABLE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00095366/00001
 Material Information
Title: Data refinement of mixed specifications : a generalization of UNITY
Series Title: Department of Computer and Information Science and Engineering Technical Report ; 96-010
Physical Description: Book
Language: English
Creator: Sanders, Beverly A.
Publisher: Department of Computer and Information Science and Engineering, University of Florida
Place of Publication: Gainesville, Fla.
Copyright Date: 1996
 Record Information
Bibliographic ID: UF00095366
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.

Downloads

This item has the following downloads:

1996208 ( PDF )


Full Text
















Data Refinement of Mixed Specifications: A

Generalization of UNITY

Beverly A. Sanders *
Department of Computer and Information Science and Engineering
University of Florida
Gainesville, FL 32611-6120
fax: (352) 392-1528
e-mail: sanders@cis.ufl.edu

TR 96-010



Abstract
Data refinement is an important and widely used technique for pro-
gram development. In this paper, we give predicate transformer based
semantics and refinement rules for mixed specifications that allow specifi-
cations to be written as a combination of abstract program and temporal
properties. Mixed specifications may be considered a generalization of the
UNITY specification notation to allow safety properties to be specified
by abstract programs in addition to temporal properties. Alternatively,
mixed specifications may be viewed as a generalization of the UNITY pro-
gramming notation to allow arbitrary safety and progress properties in a
generalized 'always section'. The UNITY substitution axiom is handled
in a novel way by replacing it with a refinement rule. The derivation of a
distributed mutual exclusion algorithm is given to illustrate the method
on a non-trivial example.


1 Introduction

Data refinement is an important method for program development where ab-
stract data structures are replaced by more concrete data structures that have
desirable properties (efficiency, distribution) for an implementation. During re-
finement, large atomic actions may be broken up into a group of smaller ones,
*This work was done while the author was with the Swiss Federal Institute of Technology
(ETH Ziirich) and California Institute of Technology ans was supported by Swiss National
Science Foundation Grant 5003-34260
















and the amount of non-determinism maybe reduced. For example, in the devel-
opment of a distributed program, one might first give a specification based on
simple (large atomic) actions on shared variables, then transform it in a series
of steps to a specification that can be implemented using message passing.
In [C'\I'1], UNITY is used to develop a variety of algorithms using this ap-
proach. UNITY comprises a notation for specifications, a notation for programs,
and a logic with proof rules for reasoning about specifications, and for showing
that programs satisfy specifications. The recommended method for program
development is to give a specification as a set of temporal (safety and progress)
properties. The specification is refined, and then finally a program, is proposed
and shown to satisfy the properties. Although there has been some work on
the refinement of UNITY programs ,,''.. Ii,',i UK''-I], for reasons discussed
later, their semantics is problematic [UK93] and in practice program refinement
is limited to special cases.
Our experience has shown that it is often convenient to be able to use a
combination of an abstract program and temporal properties. Often, the safety
properties are easier to specify using an abstract program, while the progress
properties are more conveniently specified using properties. In some situations,
a program may be given, and the task is to refine it to one satisfying additional
constraints, where the additional constraints are given as properties. Mixed
specifications allow programs and properties to be freely combined. UNITY
programs and specifications correspond to the special cases of a mixed speci-
fications with no properties or an empty program, respectively.1 Mixed spec-
ifications are refined until they are in a form that can be implemented on the
desired architecture.
After giving a brief introduction to the relevant theory about predicate trans-
formers, we define a simple specification as an initial condition, a set of variables,
and two predicate transformers: one for safety and one for progress. Then, a
refinement relation on specifications is defined. We also give an operational se-
mantics for specification refinement and prove the soundness of refinement with
respect to the semantics. The next step is to define the notation of mixed spec-
ifications and give its semantics in terms of simple specifications and develop
convenient rules for refining mixed specifications directly. The use of mixed
specifications is illustrated by giving a non-trivial example: the development
of a modified version of the class of distributed mutual exclusion algorithms in
[San87]. In conclusion,


2 Preliminaries

Following [BvW90], let var be be a countable set of program variables where
each variable x is associated with a nonempty set Dx of values. A state on var
1There are minor differences between UNITY and mixed specifications that are described
in section 4.2.















is a function mapping every x in var to a value in Dx. Evar is the state space
(set of all states) on var.
A predicate is a Boolean valued function on a state space. The predicate
space on Evar is denoted P(var) and forms a complete Boolean lattice with order
p < q = [p q]. Square brackets are the everywhere operator from [DS90]
and indicate universal quantification over a state space. Given a predicate
p E P(var), and a set of variables w C var, we define (t w).p, the restriction of
p to w, as the weakest predicate stronger than q that does not depend on any
variables not in w:

(( w).p).u = (VT :.W.T = : p.r)
where t .w.r is the projection of state r onto the variables in w.
Similarly, for q E P(w), (t var).q is q viewed in the expanded state space
Evar
A predicate transformer is a function from predicates to predicates. In gen-
eral, the argument and result predicates need not be on the same underlying
state space. A predicate transformer f is monotonic if it satisfies the following
condition:

[p = q] = [f.p = f.q] (1)
P(var) forms a complete Boolean lattice with top element true (the predicate
that maps every state to T), bottom element false (the predicate that maps
every state to F), p < q = [p q] and meet and join are conjunction, A,
and disjunction, V, respectively. In addition, the set of monotonic predicate
transformers from 'P(vl) 'P(v2), denoted Mtransvl v2 is a complete lattice
with pointwise extended order fl < fl (Vq : [fl.q = f2.q]). Meet and join
are also denoted with A and V where (fl A f2).q fl.q A f2.q and (flV f2).q -
fl.q V f2.q. (Backwards) functional composition of predicate transformers is
denoted with ';'

(f; g).q f.(g.q). (2)
We will often be interested in subsets of Mtrans that satisfy other properties
in addition to monotonicity. For example:


strict w.r.t. false [f.false false] (3)
strict w.r.t. true [f.true = true] (4)
disjunctive [f.(3w : w W : pw) (3w : w E W : f.pw)] (5)
conjunctive [f.(Vw : w W : pw) (Vw : w c W : f.pw)] (6)
strengthening f < id (7)
weakening id < f (8)
idempotent (Vq : [f.(f.q) f.q]) (9)















Conjunctivity and disjunctivity need not hold for arbitrary bag W. If f is
conjunctive for finite W, we say f is finitely conjunctive, if f is conjunctive
for non-empty W, we say f is positively conjunctive, etc. Disjunctivity can
be qualified similarly. Clearly strengthening, weakening, and idempotence, are
defined when f.p and p are predicates on the same state space.
A few additional definitions and results used later are collected below.
For predicates p and q on the same state space, imp.(p, q) is the least mono-
tonic predicate transformer satisfying [p = imp.(p, q).q]

[imp.(p,q).r pA [q = r]] (10)
Thus imp.(p, q) satisfies

[p > imp.(p, q).q] (11)

(Vf : [p = f.q] = imp.(p, q) < f) (12)

For the special case where [p = q], we also have that imp.(p, q) is strict w.r.t.
false and strengthening:

[p = q] = imp.(p, q).false = false (13)
and

[p = q] = imp.(p, q) < id (14)

f V g is the least monotonic transformer that refines both f and g and is
defined as:

[(f V g).p f.p V g.p]
The following theorems are easily obtained from the definitions:

f f Vg (15)

g < f = (f V g) < f (16)

Guard transformers We use the predicate transformer (p) as defined in
[Hes92, BvW90].

[(p).q (p > q)] (17)
















3 Specifications and refinement


3.1 Sequential programs and the refinement calculus

In the refinement calculus for sequential programming [MG90, ;\'1il, G;\1'..
Bac88, BvW89], a command, or program, is associated with its weakest precon-
dition predicate transformer: for command s E Mtrans,_,, and postcondition
q E P(v), s.q holds for exactly the set of initial states for which s is guaranteed
to terminate in a state satisfying q.
If sl < s2, then we say that sl is (algorithmically) refined by s2 since for
any precondition where sl is guaranteed to terminate satisfying q, so is s2. We
can consider sl to the specification, and s2 to be an implementation, where
correctness is proved by demonstrating sl < s2. The healthiness conditions
(for implementability) are strictness w.r.t. false and positive conjunctivity.
Commands that do not satisfy these conditions may nonetheless play a role in
program development L\1... i BvW92].
Data refinement involves changing the state space. We have a program
s E MtransA A on an abstract state space, and want to refine it to a pro-
gram that operates on a different, state space referred to as the concrete state
space. In the literature, many formal approaches have been used to describe
the relationship between the abstract and concrete programs [Hoa72, Lam94,
Lyn89, CU89, Jon91]. We follow the approach of [BvW89, C; 1'1] and represent
the relationship between the concrete and abstract states spaces as a command
taking states of the concrete state space to the abstract state space, i.e. as an
element of MtransA-c. Then, we say that sl E MtransA A is data refined
by s2 E Mtransc-c through command rep E MtransAc if

sl < reps2 rep; sl < s2; rep. (18)

rep is required to be strict w.r.t. false and positively disjunctive. As with
algorithmic refinement, sl is considered the specification, s2 is the implemen-
tation, and a proof of correctness comprises finding an appropriate rep and
demonstrating (18).

3.2 Simple specifications for concurrent programs

In the refinement calculus for sequential programs, the semantics of a program
is the relationship between the initial and final states, and termination is the
only progress property. In this section, we use predicate transformers to define a
semantics suitable for concurrent programs (with interleaving semantics) where
we are interested in making statements about the sequence of states generated
by non-terminating computations.2
2A terminating computation can be turned into a non-terminating one by repeating the
final state infinitely often.
















A specification is a tuple (var, init, f, g) where var is a set of typed variables
defining the state space, init is a predicate on the state space indicating the
allowed initial states, and monotonic predicate transformers f and g. f is the
safety transformer and defines the next state relation, in other words, we inter-
pret f as the precondition of a (non-deterministic) command that is repeatedly
executed. g is a transformer which defines progress (leads-to) properties. f is
strict w.r.t. true and g is district.
A computation c is an infinite sequence of states, (co, c, c2 ...). A compu-
tation satisfies a simple specification if all its states belong to the state space
defined by the variables, the first state satisfied the initial condition, and the
semantics of the predicate transformers are respected:
c sat (var, init, f, g) =
(Vi : i > 0 : ci C Eva) (19)
init.co = T (20)
(Vi : (Vq : f.q.ci = q.ci+l)) (21)
(Vi : (Vq : g.q.ci (3k : k > i : q.cm))) (22)
In other words, [p = f.q] implies that in every computation, if at any point
p holds, then q hold on the next step. Also, [p = g.q] implies that in every
computation, if p holds at some point, then at the current point, or at some
point in the future, q holds.
It has not been required that f be conjunctive. However, it is shown in
the appendix that there exists a conjunctive predicate transformer f and an
idempotent, weakening predicate transformer g such that
c sat (vars, init, f, g) = c sat (vars, init,f,g) (23)
f is the weakest predicate transformer describing the next state relation and
corresponds to the predicate transformer awp [C','i.'] g corresponds to the
weakest leads-to predicate transformer wit [Kna90, JKR89]. Being able to re-
place f with an equivalent conjunctive transformer and g with an equivalent
weakening, idempotent transformer is helpful in practice as these characteris-
tics yield useful metatheorems about safety and progress [C''i'.]

3.3 Refinement

3.3.1 Algorithmic refinement
A specification A = (var, init, f, g) is algorithmically refined by a specification
A' = (var', init', f', g'), denoted A C A' if and only if all computations of A'
are computations of A.
A A' (Vc : csat A' csatA) (24)
The following rule is an obvious extension (to include the progress trans-
former and initial condition) of algorithmic refinement for sequential programs.















Algorithmic refinement rule

AC A' <-
Evar = Evar' A (25)
[init' 4 init] A (26)
f< f' A (27)
g < g' (28)

There may be states which are unreachable in any computation satisfying
the specification. We say that I is invariant (always true) in A if

(Vc : c sat A: (Vi : i > 0 : I.ci)). (29)

If [init = I] and [I 4 f.I], then I is invariant. Note that if two specifications
have the same state space and initial conditions, and their transformers have
the same value on reachable states, they yield the same set of computations,
giving the following refinement rule:

Invariant Refinement Rule

[init = I] A [I = f.I] =
(var, init, (I); f; (I), (I); g; (I)) E (var, init, f, g) (30)

The proof involves straightforward predicate calculus using (29). In section
4.2, we discuss how this rule gives a novel alternative to the UNITY substitution
axiom.
Algorithmic refinement in the other direction

(var, init, f, g) E (var, init, (I); f; (I), (I); g; (I)) (31)
follows immediately from the algorithmic refinement rule and [fA < (I); fA] and
[gA
3.3.2 Data refinement
Algorithmic refinement requires that the two specifications have the same state
space. Data refinement allows us to carry out refinements where the speci-
fication A = (varA, initA, fA, gA) on an abstract state space is refined to a
specification C = (varc, initc, fc, gc) on a concrete state space. To this end,
we introduce a conjunctive, disjunctive, and strict w.r.t. false predicate trans-
former rep E MtranvarA-~, arc that represents the weakest precondition of a
deterministic command from the concrete to the abstract state space. With
algorithmic refinement, A C C holds if the computations of C are a subset of
the computations of A. Here, A C ,.pC if for each computation of C, applying















rep to each state yields a computation of A. Since rep is deterministic, a is
obtained from c by applying rep to each state:
a from c via rep = (Vi : i > 0: (Vq : q E P(varA) : (rep.q).ci = q.ai)).(32)

Then data refinement is given by

A C repC = (Vc : c sat C : (3a :a sat A: a from c via rep)) (33)
In many approaches to refinement, the specification notation will distinguish
between local and interface variables, and the interface variables are the same
in both the concrete and abstract specifications. The abstract specification is
refined by the concrete specification if the computations of the concrete are a
subset of the computations of the abstract after projecting each state of each
computation onto the interface variables. Interface and local variables have not
been built into the notation for simple specifications, but this situation can
be accommodated by letting the interface variables appear in varA and varc
and requiring that for all predicates p that depend only on these variables,
[rep.p p].

Data refinement rule Let rep be conjunctive, disjunctive, and strict w.r.t.
false.


A C reC <
rep E MtransarA var. (34)
[initc = rep.initA] (35)
rep;fA < fc;rep (36)
rep;gA < gc;rep (37)

Proof of Soundness: The command rep is guaranteed to terminate when
executed from states satisfying rep.true. Thus invariant rep.true in C guaran-
tees that (Vc : c sat C : (3a :: a from c via rep). We show that (35) and (36)
imply (rep.true).co and [rep.true = fc.(rep.true)].

[initc = rep.initA]
= { rep monotonic }
[initc = rep.true]

rep; fA < fc;rep
{ definitions of < ; }
(Vq : [rep.(fA).q = fc.rep.q])
S{ q := true}
[rep.(fA.true) = fc.(rep.true)]
{ fA strict w.r.t. true }















[rep.tirue = fc.(rep.irue)]


Now, we show that for any a obtained from c via rep, a sat A.

Proof of initA.ao:
initc.co
S{ (35)}
(rep.initA).co
I{ a from c via rep }
initA.ao

Proof of (21):
(Vq: q E P(varc) : fc.q.c i q.ci+i)
S{ predicate calculus }
(Vq : q E P(varA) : fc.(rep.q).ce j rep.q.ci+i)
S{ (36)
(Vq q (E P(varA) : rep.(fA.q).c i rep.q.ci+i)
I{ a from c via rep }
(Vq : q E P(varA) : (fA.q).ai = q.ai+)

Proof of (22):
(Vq : q E P(varc) : gc.q.ci = (3k : k > i : q.ck)
S{ predicate calculus }
(Vq : q E P(varA) : gc.(rep.q).ci = (3k : k > i : rep.q.ck)
S{ (37) }
(Vq : q E P(varA) : rep.gA.q).Ci = (3k : k > i : rep.q.ck)
I{ a from c via rep }
(Vq : q P(varA) : gA.q.ai (3k : k > i : q.ak)


A insight of practical value that can be gleaned from the above proof is that
the refinement rule can only be satisfied when rep.true is invariant.
Typically several refinements are performed and transitivity of data refine-
ment is essential. The following is straightforward from the definition:

A EreplC A C rep2D > A Erep2;replD (38)


4 Mixed Specifications

In practice, one needs a notation for predicate transformers. We propose a
particular notation called mixed specifications (mspecs) from which the safety
and predicate transformers can be derived along with rules for refining mspecs
directly.
















Syntactically, a mixed specification comprises a set of typed variable dec-
larations, a predicate representing the initial condition, a possible empty set
of multiple, conditional assignment commands, and a possibly empty set of
invariant, next, and leads-to properties. An mspec with an empty commands
section is semantically and syntactically the same as a UNITY specification. An
mspec with an empty property section is syntactically the same as a UNITY
program. An example is given below. For a more detailed description of syntax,
see [C'\I-]
On one hand, mixed specifications can be viewed as a generalization of the
UNITY [C\I--, Mis92b] specification notation. In (new) UNITY, safety proper-
ties are given by invariant and next3 properties, where invariant p means that
p holds in every state of every computation, and p next q means that in every
computation, if at some point p holds, then on the next step q will hold, and it
is also required that [p = q]. Progress properties are given by leads-to where
p z- q means that for all computations, if at some point p holds, then q holds
at that point or eventually q will hold. In mixed specifications, we can also
specify safety properties with an abstract program given by a set of universally
conjunctive, always terminating commands.
On the other hand, mixed specifications may be viewed as a generalization
of the UNITY program notation. A UNITY program comprises a set of vari-
able declarations, a commands section containing a set of conjunctive, always
terminating commands, and an "always -.. ..... in which simple functional
relationships between variables may be specified. An equation in the always
section is a kind of invariant. Mixed specifications generalize the UNITY pro-
gramming notation renaming the always section the property section and ad-
miting arbitrary invariant, next, and leads-to properties instead of a restricted
class of invariants. Although notation for nondeterministic commands has not
been explicitly given, non-deterministic commands are allowed by the theory.
For simplicity, we only consider well-formed mspecs: for each next property
p next q, [p = q], and for each invariant property invariant p, init = p, and for
each property p -' q, q f false.

Example: Distributed Mutual Exclusion This problem is a classic prob-
lem in the area of distributed algorithms and can be informally specified as
follows:
Given a distributed systems comprising a fixed set NODES of nodes with
typical elements u, v, w, and where the states of the nodes may cycle between
thinking, hungry, and eating; the algorithm should guarantee that at most one
node is eating at any given time, and that a hungry node eventually eats.
For a node u, we let u.state be a variable which can take the possible values
t, h, e for thinking, hungry, and eating. For convenience, we let u.t be shorthand
for u.state = t and similarly for u.h and u.t. When we quantify over nodes,
3In I.- -.I this property is called co for constrains. I use next since it is more suggestive.
















we will assume the range is all nodes in NODES and when we use u, v, w in
properties, we assume there is an instance of the property for every value.
The initial specification is given by the following mspec:

MO

Variables

(Vu : u.state {t,h,e})

Initial Condition

Init = (Vu : u.t) (39)

Commands

u.state := h if u.t (40)

u.state := e if u.h (41)

u.state :=t if u.e (42)

Properties

u.e C u.t (43)

invariant u.e A v.e = u = v (44)

u.h -. u.e (45)

The commands and (43) can be taken as given behavior of the nodes, where
(43) indicates that a node will not continue eating forever. The mutual exclu-
sion property is specified with an invariant (44). Our formulation says that if
two nodes are eating at the same time, then they must actually be the same.
The condition that all hungry nodes eventually eat is specified with a leads-to
property (45). Informally, we could generate the computations satisfying this
mspec as follows: Start in a state satisfying the initial condition and at each
step, nondeterministically choose a command. If the condition is satisfied, per-
form the assignment, otherwise skip. Eliminate any computation that does not,
in addition, satisfy the three properties (43, 44, 45)..
In the next section, we define the semantics of mspecs and develop some
theory. Later, we will come back to this example and refine the algorithm to a
form that is implementable and suitable for a distributed system.
















4.1 Semantics


In this section, we show how to construct the safety and progress transformers
that formally define the semantics of specifications.

Safety Transformer The safety transformer f of a well formed mspec is
determined by its commands section, and next and invariant properties. First
consider the commands section. The operational meaning of the commands sec-
tion is that at each step, one of the commands is non-deterministically chosen
and executed atomically. For nonempty commands section, let rvar (restricted
variables) be the subset of the variables which appear on the left side of some
command. Variables not in rvar are not constrained by the commands sec-
tion, and each commands section implicitly contains the command skip (where
wp.skip = id), allowing stuttering steps. Allowing stuttering steps makes re-
finements that reduce the atomicity of individual commands possible.

[uwp.q (Vs : s E commands U{skip} : wp.s.(({ rvar).q))] (46)

For an empty commands section, rvar = and we obtain

[uwp.q [q]] (47)
If the commands section is empty, then the predicate transformer corre-
sponds to the most non-deterministic always-terminating command. Since each
wp is conjunctive, strict w.r.t. false, and strict w.r.t. true, so is uwp.
The next and invariant properties in the property section impose additional
constraints on the allowed state changes which result in a weaker safety trans-
former. Each next property pi next qi corresponds to a predicate transformer
imp.(pi, qi), while an invariant property invariant pj corresponds to a predi-
cate transformer imp.(pj,pj). Since in a well-formed mspec, for each property
pi next qi, we have [p = q], thus we know that imp.(pi, qi) is strengthening and
strict w.r.t. false.
The least monotonic transformer which refines uwp and all of the transform-
ers obtained from safety properties is obtained by taking their disjunction.

f = uwp (48)
V (Vi : pi next qi is property : imp.(pi, qi))
V (Vi : invariant pi is property : imp.(pi,pi))

f is strict w.r.t. true since uwp is, and monotonic, strengthening, and strict
since each disjunct is. It isn't conjunctive in general. As mentioned earlier,
a conjunctive predicate transformer, f, that yields an equivalent specification
exists. For the case of a property section with no safety properties, f = uwp.
















Progress Transformer The progress transformer for an mspec is determined
by the set of leads-to properties. For each leads-to property pi qi, we get a
transformer imp.(pi, qi). Since in a well-formed mspec, qi f false, imp.(pi, qi) is
strict with respect to false. The disjunction of these is the the least monotonic,
strict w.r.t. false transformer which refines all of the transformers obtained
from the leads-to properties and is weakening and district is

[g (V/i : pi q is property : imp.(pi, qi)) V id] (49)

Thus, for an mspec with no leads-to properties, g = id. Also, as discussed earlier,
an idempotent, weakening transformer g that yields an equivalent specification
exists.


4.2 Comparison with UNITY

An mpsec has roughly the same operational semantics as a UNITY program ex-
ecuting the commands section, plus additional constraints on the computations
given by the properties. There are two differences: the treatment of variables
that do not appear on the left side of any assignment, and the lack of built-in
fairness assumptions in mspecs.
In UNITY, when a command is executed, it is assumed that the other vari-
ables of the program remain constant. An exception are variables defined by
the always section. Consider the following example:

declare
x, y: integer
always
y = x
commands
:= x +1

In UNITY, one would prove (x = 0 A y = 0) next (( = 0 A y = 0) V (x = 1 A y =
1)) by first replacing y with x in the formula, then showing that x = 0
wp.x := x + 1.(x = 0 V x = 1) holds. Attempting to calculate the wp without
first doing the substitution would give incorrect results. With mspecs, the
equation y = x would appear as an invariant property in the property section.
We would show (x = 0) next (x = 0 V x = 1), then use y = x next y = x to
obtain (x 0 A y =x)next (( 0Vx= 1) Ay x).
In UNITY programs, each command in the commands section is assumed to
be attempted infinitely often (weak fairness), while in mspecs, we do not make
any fairness assumptions about commands in the commands section. There are
several reasons for this. One reason is theoretical: with fairness assumptions,
the progress properties of an mspec are not completely characterized by the set
of leads-to properties, so a single predicate transformer for progress would not
suffice. (See [UK93]). More pragmatic reasons are that experience has shown
















that when using an abstract program as a specification notation the connection
between the desired behavior (leads-to properties) and fair commands is not
transparent. Very often, fewer progress properties are actually required than
specified when fairness is implicit; and refining the atomicity of individual fair
commands is quite difficult except for special cases.
An mpsec is considered to be implementable if we can assume that all re-
maining properties are satisfied by the execution environment. A typical such
assumption is fair execution of certain commands in a commands section. Such
assumptions, allow one to conclude that certain progress properties will be sat-
isfied. However, not building this into the formalism allows more generality and
provides a framework in which other kinds of assumptions can be made. For
example, an assumption that a communication channel doesn't lose too many
messages can be conveniently stated using leads-to properties, which we then
simply assume to hold. We might want to assume that certain restricted invari-
ant properties (i.e. those that satisfy the condition for appearing in a UNITY
always section) hold in an implementation.

4.3 Refinement of mixed specifications
In this section, we give several useful results for showing one mixed specification
refines another.
Both f and g are given by the disjunction of a (possibly infinite) set of pred-
icate transformers. (This construction is essentially the same as the program
conjunction, 1, described in [CG I'1].) We will use h to indicate either f or
g. The next theorem shows that it suffices to refine the individual component
transformers whose disjunctions make up f and g (uwp, imp(pi, qi), etc.)4

Theorem Let h (Vi : i V : hi) and h' (Vi : i V: h') where V is any
set. Then

(Vi : i V : rep; hi < h'; rep) 4 (rep; h < h'; rep) (50)

Proof:

rep; h
{ definition of h }
rep; (Vi : i C V : hi)
{ rep disjunctive and strict w.r.t. false }
(Vi : i V : rep; hi)
< { hypothesis, predicate calculus }
(Vi: i V : h'; rep)
{ predicate calculus }
(Vi : i V : h); rep

4This is essentially Lemma 7.6 in [GM91].















{ definition of h' }
h'; rep


The theorem can be applied to refine both the safety and progress trans-
formers by instantiating h with f and g respectively.
Next, we show that the transformers constructed from the invariant next
and leads-to properties can be refined by replacing each p appearing a property
with rep.p 5

Theorem

rep; imp.(p, q) < imp.(rep.p, rep.q); rep (51)

(imp.(rep.p, rep.q); rep).r
{ definition }
rep.p A [rep.q = rep.r]
{ rep monotonic }
(i) rep.p A [q = r]
S{ Predicate Calculus, [rep.true true] }
(ii) rep.p A rep.[q = r]
{ rep conjunctive }
(iii) rep.(p A [q = r])
{ definitions }
(rep; imp.(p, q)).r


Remark: The application of everywhere brackets gives either true, the predicate
with value T on every element of the state space, or false, the predicate with
value F for every element of the state space where the state space that true and
false belong to is determined by the context. In (i), [q = r] E P(C), in (ii),
[q = r] E P(A), and in (iii), [q = r] E P(C). For the sake of brevity, more
precise notation is not introduced here. End of Remark.
At this point, we can refine an mspec by proposing a new commands section
and showing that rep; uwpA < uwpc; rep and replacing each property p next q,
invariant p, or p -- q with rep.p next q, invariant rep.p, or rep.p -- rep.q,
respectively.
The next theorem shows how next and invariant properties can be elimi-
nated by showing that they are already satisfied by uwp.

Theorem: Property elimination If [p u uwp.q], then p next q can be
eliminated from the property section. If [p u uwp.p] in a well-formed mspec,
then invariant p can be eliminated from the property section.
5This is similar to theorem 8.1 in [GM91] although the proof is simpler.















Proof: Follows from (16) and (12).
The next rule shows that we can utilize invariants of the abstract program
together with the invariant rule without having to explicitly show an invariant
property in the refinement.

Invariant Theorem
[I = fA.I] A rep; fA < (rep.I); fc; rep = [rep.I = fc.(rep.I)] (52)
Proof:
rep; fA < (rep.I); fc; rep

[rep.(fA.I) => (rep. I); fc; rep).I]
{ [I = fA.I] and fA strengthening }
[rep. I ({rep.I); fc; rep).I]
{ definition of (I), predicate calculus }
[rep. I (rep.I => fc.(rep.I))]

[rep.I fc.(rep.I)]

Together with the above, we use the fact that [initA = I] A [initc =
rep.initA] = [initc = rep.I].

Metatheorems The final way to manipulate mixed specifications is by using
metatheorems to eliminate properties by showing that they are implied by other
properties. This is the major activity when using UNITY for program deriva-
tion. Below we list several useful metatheorems. Some follow directly from
the properties of the predicate transformers [C("v'], f and g and the shapes of
f and g. Others, which involve the interplay between the safety and progress
transformers follow from the semantics. Proofs in the context of UNITY are
given in [C'\I-\ Mis92a]. In all cases, we require that the well-formedness be
maintained. Unless otherwise stated, the range of w is W, an arbitrary set.

Conjunction
p next (Vw : q) (Vw : w c W: p nexi q) (53)
For finite W:
p (Vw : q,) (Vw :: p q,) A (Vw :: qw next q,) (54)

Disjunction
(3w :: p,) nexi q ( (Vw :: pw nexi q) (55)
(3w :: pw) q = (Vw : p-, q) (56)















Strengthen left and weaken right sides

p next q = p' next q' if [p' = p] A [q = q'] (57)

p q p' q' if [p' = p] A [q = q'] (58)

Transitivity
p next q = p next r A r next q (59)

p.q p p rAr.q (60)

Implication

p- q invariant (p = q) (61)

PSP (progress-safety-progress)

pAr ((qA r) V (-r A s)) p qA r next s (62)

Cancellation

p-qVs < (p-qVr)Ar-s (63)

Induction Let M : Eva, W be a total function and (W, <) be well-founded.

p -q (Vm:(pAM=m) -((pAM
Completion

p- (Vw:: q) Vr (Vw:: p- q V r) A(Vw :qu, next q V r) (65)

Substitution

p next q AI pA J next q A invariant IA invariant J (66)

p - qAI pA J -- q A invariant IA invariant J (67)

The substitution rule follows from the invariant refinement rule, giving an ap-
proach to the UNITY 'substitution axiom' based on refinements. (See [ ii'il]
for an approach based on the notion of a strongest invariant).

Denoting rep rep is the weakest precondition of a deterministic command
from the concrete to abstract state spaces. Often, this command is most easily
represented by a function m : Ec -- A with domain dom. Then

[rep.r dom A (a := m.c).r] (68)
















4.4 Discussion


Mixed specifications have been presented as a generalization of UNITY, allowing
more freedom in writing specifications, and adding general program transfor-
mations to the repertoire of practical techniques that can be used in program
derivation. Incidentally, a novel approach to the substitution axiom, based on
refinement, has been proposed.
The approach could also be viewed as a generalization of the refinement cal-
culus for concurrent and reactive programs. In doing this, two new problems
arose: the problem of eliminating unreachable states, and progress. Unreachable
states were handled with the notion of invariant refinement. Progress was han-
dled by introducing a second predicate transformer for progress. The weakness
of the approach is that the safety and progress transformers are simply given,
and don't necessarily have the relationship between awp and wit that allows
theorems such as PSP to be shown from the properties of the transformers. We
had to resort to the semantics to prove this. A theoretically nicer approach is
used in [Bac89]. Here, the type of progress allows is fairness. Fairness is encoded
as a safety property by adding counters that bound the number of steps that can
occur without executing a command. Practically, however, mixed specifications
are more useful. Not only is fairness not the progress property one wants to
use for high level specifications, but using it this way clutters up specifications
considerably and makes checking refinement more difficult.
Other approaches [Lam94, Lyn89, Jon91] don't use predicate transformers
or the refinement calculus at all, and are formulated in completely in temporal
logic (or something similar). The advantage of the method presented here is
that we still have most of the benefit of the predicate transformer approach,
including the theory of predicate transformers and calculational style proofs
along with a familiar program notation.


5 Case Study

In this section, we illustrate the use of the method presented here to refine the
specification for a mutual exclusion algorithm given earlier to one suitable for
implementation in a distributed system.

5.1 Information structures

Many different solutions to the mutual exclusion problem have been proposed.
For the algorithm of primary interest here, we define a so-called information
structure: for each node we have a (fixed) request set, denoted u.R, and a
(fixed) inform set u.I. Informally, the request set is the set of node from which
permission to eat must be requested, while the inform set is the set of nodes
which must be informed when the state changes from eating to thinking. As
discussed in [San87], various choices for the information structures yield several















previously published algorithms as special cases. The algorithm presented here
has a simpler approach to deadlock avoidance than the one given in [San87]
(which was not correct).
In addition to the information structure, each node u has a variable u.TS
holding an integer time stamp, a variable u.G holding a set of node id's, and
a variable u.S holding a node (id), integer (time stamp) pair or a special value
1. We will compare node, timestamp pairs as follows: (u, u.TS) < (v, v.TS) -
u.TS < v.TS V (u.TS = v.TS A u < v), and (u, u.TS) < (v, v.TS) u.TS <
v.TS V (u.TS = v.TS A u < v). This is the usual total ordering on time
stamps [Lam78]. In addition, I < (u, u.TS) < T. For convenience, we use the
abbreviation u.ts = (u, u.TS).
The following invariants capture the essence of our algorithm:

invariant u.e = u.R = u.G (69)


invariant v C u.G = (70)
(v E u.I 4 v.S = u.ts) A u.ts < v.ts

Intuitively, u.G holds the set of nodes which have 'granted permission' for u
to eat. Thus (69) says that u only eats after it has received permission from all
nodes in its request set. The invariant (70) essentially says that if v has granted
permission to u to eat, then v remembers this if v is in u's inform set (by storing
u.ts in v.S) and that v will only grant permission when u.ts < v.ts.
Assuming that the request set includes the inform set, and that each node
belongs to its own inform set, it suffices that for each pair of nodes, either their
inform sets have a non-empty intersection, or they are in each other's request
set. It is easy to show that these restrictions on the information structure,
formalized in (71) and (72) together with (69) and (70), imply (44).

(Vu : u.I C u.R A u E u.I) (71)

(Vu, v : (u.I n v.I # ) V (u E v.R A v u.R)) (72)

Proof:

u.e A v.e
4 { conjunction, (69) }
(u.R = u.G) A (v.R= v.G)

(Vw: w C u.R: w C u.G) A (Vw: w C v.R: w C v.G)
{ (71) }
(Vw: w u.I: w C u.G) A (Vw: w C u.R: w C u.G)A
(Vw,: w C v.I: w C v.G) A (Vw: w v.R: w C v.G)
S { (70) }
















(Vw : w u.I: w.S
(Vw : w v.I: w.S


u.ts) A (Vw : w E u.R : u.ts < w.ts)A
v.ts) A (Vw : w v.R : v.ts < w.ts)


(Vw: w E u.I A w v.I : v.ts = w.S A u.ts = w.S)A
(u E v.R ? v.ts < u.ts) A (v E u.R = u.ts < v.ts)

(Vw : w E u.I A w E v.I : v.ts = u.ts)A
(u E v.R A v u.R = u.ts = v.ts)
S { (72)}
u.ts = v.ts

U= V


Now, the task is to design an algorithm that maintains the invariants (69,70)
while satisfying the progress property. This will be done by constructing a new
mspec, which refines the previous one and includes the new variables. The new
mspec is given next, followed by explanations.

M1

Variables

(Vu :
u.state : {t, h, e};
u.G : set of nodeld;
u.TS : nat;
u.S : (id : nodeld,t : nat) U )

Abbreviations


u.minreq = (u.h V u.e) A (Vv : v.h V v.e : u.ts < v.ts)


Initial Condition


Init = (Vu : u.t A u.G = 0 A u.S = I)


Commands
BECOME HUNGRY


u.state := h if u.t


START EATING AFTER ALL NODES IN REQUEST SET HAVE GRANTED PERMISSION

u.state := e if u.R = u.G A u.h (76)

















v GRANTS PERMISSION TO u

u.G := u.G {v} (77)
if u.h A v E u.R A (u.ts < v.ts A v E u.I = v.S = u.ts)

U FINISHED EATING, EMPTIES u.G AND INCREMENTS TIME STAMP

u.state, u.G, u.TS, u.S:= t, 0, u.TS + 1, I if u.e (78)

IF v E u.I, V RECORDS U'S INFORMATION IN v.S BEFORE GRANTING PERMIS-
SION

v.S := u.ts if v E u.I A u.h A u.ts < v.ts A v.S = 1 (79)

v RESETS v.S ONCE ENTRY NO LONGER HOLDS GRANT FROM v

v.S := L if (Vw, n : v.S = (w, n) = v V u.G) (80)

U INCREASES TIMESTAMP VALUE WHILE THINKING

u.TS := max(v.TS + 1, u.TS) if u.t A u c v.R A v.h (81)

v REVOKES GRANT GIVEN TO u TO BREAK A POSSIBLE DEADLOCK.

u.G := u.G {v} (82)
if u.h A v E u.I A u.R 7 u.G A (3w : w.h A v E w.I A (w.ts < u.ts))

Properties

u.e C^ U.t

invariani u.e A v.e = u = v

u.h u.e

invariant u.e = (Vv vE u.R : v E u.G)


invariant v E u.G =
(v E u.I = v.S =u.ts A
u.ts < v.ts)

u.minreq A v E u.R v E u.G V -u.minreq (83)

(u.R = u.G) A u.h u.e (84)

At this stage in the development, we allow a thinking node to become hungry
at any time and adopt (40) without modification.
















On the other hand, in order to maintain (69), one needs to strengthen the
guard on (41) to only allow a node to start eating when it holds a grant from
all elements of its request set. These considerations give (76).
We need additional commands which allow the progress condition to be
satisfied. A first step is to add commands to establish the guard of (76) without
violating the invariant. (77) adds v to u.G.
u.G should be cleared when u stops eating, so we modify (42) to do this,
obtaining (78). In addition, the time-stamp is incremented to prevent multiple
requests with the same time-stamp.
In order for the guard in (77) to ever hold, the v.S variable must be set, so
we add (79).
The constraint on v.S is that if v E u.I and v E u.G, then v.S = u. Thus
v.S can be set to I when v is no longer in u.G, giving (80).
A command for changing the value of u.TS is needed in order to allow
arbitrary pairs of nodes to eventually satisfy (u.ts < v.ts). First, we note that
u.TS cannot be arbitrarily increased without possibly violating the condition
u.ts < v.ts which must hold while v E u.G. On the other hand, in order for
v E u.G to be established, it must be possible at some point to increase v. Thus
we introduce (81) which allows u.TS to be increased while u.t holds.
As the algorithm given so far can deadlock, we introduce a command (82)
for deadlock resolution which allows grants given to a still hungry node to be
revoked if a new request with smaller time stamp arrives.
Finally, we note that when there are multiple requests which could be
granted, in anticipation of the next refinement the command (79), includes no
constraints on which one is chosen. Requiring that the hungry node with v in its
inform set with the smallest timestamp be chosen would not be implementable
when refined to a distributed system.
In the property section, we add the invariants (69,70) as discussed above.
Two new progress properties (83,84) have been added. Informally, (83) says
that if u is hungry and u has the smallest time stamp of existing hungry nodes,
then eventually it will receive a grant from every node in its request set or
another node with smaller time stamp will make a request. (84) says that once
a hungry node has received all necessary grants, it will eventually eat.
MO C (M1 .var).idM1 follows immediately since we have only modified exist-
ing commands by adding new variables and strengthening guards, added new
commands that don't modify variables in MO, and added additional properties.
At this point, we would like to simplify M1 by eliminating as many properties
as possible. We have already seen that (69,70) imply (44), so when we absorb
(69) and (70), we eliminate (44) as well. Absorbtion of (69) follows easily from
the text of the commands section: the only command which establishes u.e,
(76) is guarded by u.R = u.G, and the only commands which falsify u.R = u.G,
(78, 82) also maintain the invariant. Absorbtion of (70) follows from a slightly
stronger property, which can be proved directly from the text.


















invariant v E u.G = (85)
(u.h V u.e) A (v E u.I = v.S = u.ts A u.ts < v.ts)

To prove this, we need only consider commands (77,78,81), (79,80), and (81)
(with u := v). These follow easily. The extra conjunct in (85) was motivated by
the proof for statement (81). Note that the proofs of the invariant properties
were very easy. This is no accident as the algorithm was constructed that way!
We also show that (83,84) together with the commands imply (45) and elim-
inate (45). This proof is considerably more involved than that of the invariant
properties above. However, by eliminating (45) at this point, we are doing the
hardest part of showing progress at a high level of abstraction.

Lemma

u.minreq -- -u.minreq (86)

Proof:

true
I { Prove directly from text of commands section }
v E u.G next v E u.G V -u.minreq
S{ Conjunction of both sides over v E u.R }
(Vv E u.R :: v u.G) next (Vv E u.R:: v u.G) V -u.minreq)
I { Completion theorem with (83) }
u.minreq u.e V -u.minreq
= { Cancellation with u.e -u.minreq (< weakening r.h.s of (43) }
u.minreq -- -u.minreq


Now we introduce a metric u.M (u.ml, u.m2) and show that it cannot in-
crease while u.h holds. Intuitively, the first component of u.M is the number
of outstanding requests with smaller timestamp than u. The second component
is an upper bound on the number of future requests with smaller timestamp.
Thus the only relevant actions involve making a request (possibly increasing the
first component of u.M but decreasing the second) or increasing a timestamp
(possibly decreasing the second component of u.M.)

Lemma Let

u.M = (u.ml, u.m2)

where

u.ml = (+w : w.ts < u.ts A -w.t : 1)
















u.m2 = (+w : w.ts < u.ts A w.t : u.ts 8 w.ts)


and
S0 if u.ts < w.ts
u.ts e w.ts u.TS v.TS if w.ts < u.ts A u < w
(u.TS v.TS) + 1 if w.ts < u.ts A w < u
Then

u.h A u.M = m A v.minreq next (87)
(u.h A u.M < m A u.minreq)
V(-v.minreq A u.h A u.M < m)
Vu.e

The next property is implied by the set of commands. The straightforward,
proof is omitted. Now, we prove u.h u.e (45).

Proof:

true
I { PSP theorem on (86,87) }
u.h A u.M = m A v.minreq -
(u.h A u.M < m) V (-(u.h A u.M = m A v.minreq) A u.e)
S { weaken right side }
u.h A u.M = m A v.minreq (u.h A u.M < m) V u.e
I { disjunction of both sides over v : v.minreq, nonempty since u.h }
u.h A u.M = m (u.h A u.M < m) V u.e
S { induction }
u.h u.e



5.2 Refinement to an algorithm with message passing

The algorithm developed above satisfies the constraints that each command
modifies data belonging to at most one node although variables from more than
one node may be read. The algorithm is refined by adding communication
channels and local variables, and by replacing commands that read variables
from more than one node with commands to send messages indicating the value
of the variables and commands to read the message and possibly save the results
in local variables.
A one-way communication channel between nodes u and v is modeled by a
variable of type sequence denoted ch,,. We include a channel in each direction
between each pair of nodes and a channel ch,, to itself. By allowing nodes to
send and receive messages from themselves, several special cases in the algorithm
can be eliminated.


u.ml
















In the next refinement, we will use rep = (t M2.var).id. In order to simplify
proving that M1 i (TnM2..va -', we will specify the meaning of each message
and newly introduced local variables using an invariant that is added to the
property section.

M2

Variables

Vu :
u.state : {t, h,e};
u.G, u.Q : set of (id : nodeld, t: nat);
u.TS : nat; u.S : (id : nodeld, t: nat) U 1;
sentYield : boolean;
(Vv :: ch,, : sequence))

Abbreviations

u.ts = (u, u.TS); (88)

SET OF NODES FOR WHICH v CAN GRANT PERMISSION

v.QG = {u\(u, n) v.Q A (u, n) < v.ts A (v u.id.I v.S = (u, n))}(89)

LEAST OUTSTANDING REQUEST FOR WHICH U IS IN NODE'S INFORM SET

u.minQI = min.({rIr C u.Q A u C r.I} U {T}) (90)

LARGEST ENTRY IN U'S REQUEST QUEUE

u.maxQ = max.(u.Q U {-}) (91)

SEND

u.send(v, msg) = ch, := ch,,; msg (92)

BROADCAST

u.broadcast(Dests, msg) = (|. : v Dests : u.send(v, msg)) (93)

RECEIVE

u.receive(v, msg) + command = (94)
( ..*....'.i./I. I/ := tail.ch u,) if head.chu, = msg
















Initial Condition


Init = (Vu : u.t A u.G = p A u.S = L A u.Q = 4 A -u.sentYield (95)
A(Vv :: ch,, = )

Commands
BECOME HUNGRY AND SEND REQUEST MESSAGE WITH TIME STAMP TO ALL
NODES IN REQUEST SET

(u.state := h ||u.broadcast(u.R, (req, u.TS))) if u.t (96)
ON RECEIVING A GRANT MESSAGE, ADD ID OF SENDER TO U.G

u.receive(v, grant) + u.G := u.G U {v} (97)

START EATING AFTER GRANTS HAVE BEEN RECEIVED FROM ALL NODES IN
GRANT SET

u.state := e if (u.R = u.G) A u.h (98)

STOP EATING AND SEND RELEASE MESSAGE TO ALL NODES IN INFORM SET
(EXCEPT SELF), RESET u.G, U.S, AND INCREMENT u.TS

(u.state, u.G, u.S, u.TS:= t, p, 1, u.TS+ 1 || (99)
u.broadcast(u.I u, release)) if u.e

INCREASE TIME STAMP IF THINKING

u.TS := max.((u.maxQ).t + 1, u.TS) if u.t (100)

RECEIVE REQUEST AND ADD REQUESTER TO REQUEST QUEUE

v.receive(u, (req, n)) + v.Q := v.Q U {(u, n)} (101)

SET VALUE OF v.S FOR REQUESTERS WITH v IN INFORM SET

v.S := v.minQI if v.S = I A v.minQI < v.ts (102)

SEND GRANT MESSAGES TO ALL NODES THAT SATISFY THE NECESSARY CON-
DITIONS AND REMOVE NODES FROM REQUEST QUEUE

v.broadcast((wl(w, *) E v.QG), grant) | v.Q := v.Q v.QG (103)

ON RECEIVING RELEASE MESSAGE, RESET v.S AND v.sentYield

v.receive(u, release) + v.S, v.sentYield := 1, false (104)

ATTEMPT TO REVOKE GRANT BY SENDING YIELD MESSAGE TO AVOID DEAD-
LOCK

v.send(v.S.id, (yield, v.S.t)) I| v.sentYield := true (105)
if v.minQI < v.S A -v.sentYield A v.S ( v.Q
















RECEIVE YIELD MESSAGE. IF STILL WAITING FOR SOME GRANTS AND YIELD
IS VALID, THEN REVOKE GRANT FROM SENDER OF YIELD MESSAGE AND ACK.

u.receive(v, (yield, n)) t (106)
((u.G := u.G- {v} || u.send(v, ack)) if u.R f u.G A u.TS = n)

ON RECEIVING ACK, RESTORE v.S ENTRY TO QUEUE

v.receive(u, ack) + v.S, v.Q, v.sentYield := 1, v.Q U {v.S}, false (107)

Properties

u.e C U.t

u.minreq A v E u.R v u.G V -u.minreq

u.R = u.G A u.h - u.e


invariant (req, n) E ch,, = u.h A u.TS = n A v E u.R (108)


invariant (u, n) E v.Q = u.h A u.TS = n A v E u.R (109)

invariant grant E ch,, = u.h A u.ts < v.ts A v E u.R A (110)
(v E u.I = v.S = u.ts)



invariant release c chuv v G u.I- u A v ( u.G (111)


invariant ack E ch,, = v.S = u.ts A v ( u.G (112)


invariant (yield, n) c chvu A u.R f u.G A u.TS = n = (113)
u.h A v E u.I A (w : w.h A v E w.I A (w.ts < u.ts))

The specification M1 captures the basic workings of the algorithm, but al-
lows individual commands to access variables of multiple nodes. In refinement
M2, each such command has been replaced by a command that only accesses
variables of a single node and communication channels. For example, in M1,
the command adding v to u.G, (77) reads variables of both u and v. Thus, we
introduce a message grant whose presence in the channel from v to u implies
that the guard of the the command, u.h A (u.ts < v.ts A v E u.I = v.S = u.ts),
holds. Since the guard depends on the values of u.h and u.ts, u must send a mes-
sage to v indicating u.h and giving the value of u.ts, thus the message (req, n)
















is introduces that indicates that the sender, say u, is hungry and u.TS = n.
The rest of the algorithm is distributed similarly. All properties not eliminated
from M1 have been kept, and the new invariants have been used to define the
messages in such a way that showing that M1 C M2 can be done by inspection.
At this point, we have the final commands section. What remains is to absorb
the invariants, and to replace u.minreq A v E u.R -. v E u.G V -u.minreq by
implementable progress properties.
The invariants that were chosen to capture the meaning of the messages and
make proving refinement easy cannot be proved directly from uwp. Instead, we
use invariant refinement with the stronger invariant I given in figure 1, which
can be eliminated by showing [I = uwp.I] and [M2.init = I]. In the figure
x c Seq means that x appears exactly once in sequence Seq, and [x y
(x A my) V (-x A y)], and x < precedes y. Note that ] is associative.
We now refine the progress property (83).
First, we note that the following invariant that follows from I
invariant u.TS = n A -u.t A v E u.R 4 (114)
(req, n) E chu, V
(u, n) c v.Q V
grant E chu, V
v u.G V
(ack E chu, A v E u.I A v.S = (u, n)),
can be converted immediately to a progress property by replacing the 4 with

Together with

(req, n) c chu, (u, n) c v.Q (115)

(u, n) E v.Q A u.minreq grant E chu, V \u.minreq (116)
grant E chu v E u.G (117)

(Aack E chuv,, A v.S = (u, n)) (u, n) C v.Q (118)

it is not difficult to obtain (83). The proof is summarized in the proof lattice6
[OL82] shown in figure 2, with the final step being to take the disjunction over
all n.
Now we refine further the individual properties given above. First, it is not
difficult to see that (115) follows from (use PSP)

(req, n) c chu, (req, n) V chu, (119)
6We use the proof lattice to summarize applications of transitivity and the cancellation rule.
A node in the lattice labeled p with n outgoing edges who's nodes are labeled qw represents
the property p -( (3w : qw)




















(Vu, v, n : u, v E Nodes An > 0
u.t =
(req, n) ( ch,, A
(u, n) $ v.Q A
grant h ch,, A
v $ u.G A
ack ( chu, A
(release 6 ch,, = (v u.I


u A v.S < u.ts))


u.h =
(v ( u.R V u.TS 0 n)

(req, n) E ch/, A ack E( chuv A (release E ch,, v E u.I u A release <
(u, n) E v.Q A ack E chuv A release ( chu,

grant E ch, A release chuv(u, n) < v.ts A (v E u.I v.S = (u, n))

v u.G A release ( cheu(u, n) < v.ts A (v E u.I = v.S = (u, n))


ack chu A v u.I A release (E chu A (u, n) < v.ts A (v u.I = v.S


(u, n)),


u.e =
(v E u.R = v E u.G) A
(req, n) ( chu, A
(u, n) v v.Q A
grant ( chu, A
ack $ ch,, A
(release chu, A
v E u.I = (u.ts = v.S)


v.S = (u, n) =
v E u.I A (u, n) < v.ts A
((release E ch,, A u.TS > n) V (u.TS
A
(yield, n) E chvu
(yield, n) 6 chvu A
vE u.I A
((u.TS = n A v.sentYield A v.minQI <
)


Sn A release chu,))





(u, n) A v.S = (u, n) A ((grant E ch,, A grant << (yield, n) V v E u.G)))


Figure 1: Invariant I for M2




























u.TS = n A minreg(u) A v E u.R


grant E ch~v





vE u.G


Figure 2: Proof lattice for u.minreq A v E u.R v E u.G V -u.minreq


-u.minreq


'uv
















(req, n) C ch,, next (req, n) C ch,, V (u, n) C v.Q


Similarly, (117) follows from

grant E ch,, -. grant ( ch,, (121)

grant C ch,, next grant C ch,, V v c u.G (122)

and (118) follows from

ack E ch,, --+ ack ( ch,, (123)

ack E ch,, A v.S = (u, n) next ack E ch,, V (u, n) C v.Q (124)

In all three of these cases, the leads-to properties can be assumed-all that is
necessary is that each message in a channel is eventually received. The next
properties can be absorbed by the commands section.
Now, we turn our attention to the more difficult task of refining (116). We
omit the details, but it is straightforward to show that for v ( u.I, the following
suffice:

u E v.QG grant E ch,, Vu a v.QG (125)


(u, n) C v.Q A u.ts < v.ts next (126)
((u, n) C v.Q A u.ts < v.ts) V grant C ch,,

v.t A (u, n) C v.Q v.TS > n V -v.t (127)

Since (125) and (127) follow provided (103) and (100) are eventually exe-
cuted we will assume these properties. (126) can be absorbed by the commands
section.
The case where v E u.I involves the deadlock avoidance mechanism. This
feature has been problematic in previously published work on similar mutual
exclusion algorithms ... i I ,. -".
First, we consider the situations where v.S = (u, n) or v.S = i. By strength-
ening the left side of (125), we obtain

(u, n) E v.Q A v.S = (u, n) A v C u.I grant E ch,, Vu a_ v.QG. (128)
Together with

(u, n) C v.Q A v.S = (u, n) next (129)
((u, n) C v.Q A v.S = (u, n)) V grant E ch,, (130)
we get

(u, n) C v.Q A v.S = (u, n) grant E ch,, (131)


(120)
















(129) can be absorbed by the commands section. From the above,

v.S = L A v.minQI < v.ts v.S = v.minQI, (132)

and

(u, n) E v.Q next (u, n) E v.Q V grant E ch,,, (133)
we can show

(u, n) E v.Q A u.minreq A v E u.I A v.S = -L (134)
grant E ch,, V -u.minreq. (135)

The final case is the possible deadlock situation: although u is the smallest
request in the system, v.S indicates that a grant has been sent to some other
node. We need to show

(u, n) E v.Q A u.minreq A v E u.I A v.S = (w, m) v.S = 1. (136)
This follow by strengthening the left side of

v.S = (w, m) A v.minQI < v.S A v.S V v.Q v.S = 1 (137)

whose proof is summarized by the proof lattice in figure 3.
The steps in the proof lattice are straightforward from the invariant and
assumed properties

v.S = (w, m) A v.minQI < v.S A v.S V v.Q (138)
(yield, m) E chw V v.S = I

(yield, m) E chw -. (yield, m) V chbw (139)

ack E chw ack chw, (140)

plus (u.R = u.G) A u.h -. u.e and u.e u.t.

5.3 Implementable Specifications
The results of the previous section are summarized in the final, implementable
specifications. In addition, we make one further optimization by noting that
the invariant I implies the following:

(yield, n) E ch,, = (u.TS = n = v E u.G) (141)

As a result, (106) can be modified to test v E u.G instead of u.TS = n. Once
this is done, the integer field in the yield message is no longer needed.

M3






















v.S = (w, m) A v.minQI < v.S A v.S V v.Q


(yield, m) E chuwedgev.S


(w, m)


w.R f w.G A w.TS m A



S w.



ack E ch,,


ch,,


VS = m w-


Figure 3: Proof lattice


w.G A w.h


w.G A


w.TS >


v.S = I
















Variables

Vu :
u.state : {t, h, e};
u.G, u.Q : set of (id : nodeld, t: nat);
u.TS : nat; u.S : (id : nodeld, t : nat) U I;
sentYield : boolean;
(Vv :: ch,, : sequence))

Abbreviations

u.ts = (u, u.TS); (142)

SET OF NODES FOR WHICH v CAN GRANT PERMISSION

v.QG = {ul(u, n) v.Q A(u, n) < v.tsA (v u.id.I v.S = (u, n))}(143)

LEAST OUTSTANDING REQUEST FOR WHICH U IS IN NODE'S INFORM SET

u.minQI = min.({rlr E u.Q A u c r.I} U {T}) (144)

LARGEST ENTRY IN U'S REQUEST QUEUE

u.maxQ = max.(u.Q U {I}) (145)

SEND


u.send(v, msg) = ch,, := c

BROADCAST

u.broadcast(Dests, msg) =

RECEIVE

u.receive(v, msg) $ command(
( .... .. . i./||. /, := ta il.


if head.ch,, = msg


Initial Condition


Init = (Vu : u.t A u.G = A u.S =
A(Vv :: ch,, = E)


_ A u.Q = 0 A -u.sentYield (149)


(II : v G Dests : u.send(v, msg))


(146)



(147)



(148)

















Commands
BECOME HUNGRY AND SEND REQUEST MESSAGE WITH TIME STAMP TO ALL
NODES IN REQUEST SET

(u.state := h l|u.broadcast(u.R, (req, u.TS))) if u.t (150)
ON RECEIVING A GRANT MESSAGE, ADD ID OF SENDER TO U.G
u.receive(v, grant) t u.G := u.G U {v} (151)
START EATING AFTER GRANTS HAVE BEEN RECEIVED FROM ALL NODES IN
GRANT SET
u.state := e if (u.R = u.G) A u.h (152)
STOP EATING AND SEND RELEASE MESSAGE TO ALL NODES IN INFORM SET
(EXCEPT SELF), RESET u.G, U.S, AND INCREMENT u.TS

(u.state, u.G, u.S, u.TS:= t, p, 1, u.TS+ 1 | (153)
u.broadcast(u.I u, release)) if u.e
INCREASE TIME STAMP IF THINKING
u.TS := max.((u.maxQ).t + 1, u.TS) if u.t (154)
RECEIVE REQUEST AND ADD REQUESTER TO REQUEST QUEUE
v.receive(u, (req, n)) $ v.Q := v.Q U {(u, n)} (155)
SET VALUE OF v.S FOR REQUESTERS WITH v IN INFORM SET
v.S := v.minQI if v.S = L A v.minQI < v.ts (156)
SEND GRANT MESSAGES TO ALL NODES THAT SATISFY THE NECESSARY CON-
DITIONS AND REMOVE NODES FROM REQUEST QUEUE
v.broadcast((wl(w, *) E v.QG), grant) | v.Q := v.Q v.QG (157)
ON RECEIVING RELEASE MESSAGE, RESET v.S AND v.sentYield
v.receive(u, release) + v.S, v.sentYield := 1, false (158)
ATTEMPT TO REVOKE GRANT BY SENDING YIELD MESSAGE TO AVOID DEAD-
LOCK
v.send(v.S.id, yield) I| v.sentYield := true (159)
if v.minQI < v.S A -v.sentYield A v.S ( v.Q
RECEIVE YIELD MESSAGE. IF STILL WAITING FOR SOME GRANTS AND YIELD
IS VALID, THEN REVOKE GRANT FROM SENDER OF YIELD MESSAGE AND ACK.
u.receive(v, yield) + (160)
((u.G := u.G {v} || u.send(v, ack)) if u.R u.G A v u.G)
ON RECEIVING ACK, RESTORE V.S ENTRY TO QUEUE
v.receive(u, ack) + v.S, v.Q, v.sentYield := 1, v.Q U {v.S}, false (161)
















Properties
NO NODE EATS FOREVER.

u.e --- U.t

FAIR EXECUTION OF (159)

v.S = (w, m) A v.minQI < v.S A v.S ( v.Q
(yield, m) E chu V v.S = I

FAIR EXECUTION OF (152)

(u.R = u.G) A u.h u.e

FAIR EXECUTION OF (157)

u v.QG grant E ch,, Vu a Q v.QG

FAIR EXECUTION OF (156)

v.S = L v.S = minQI

FAIR EXECUTION OF (154)

v.t A (u,n) E v.Q u v.TS > n V v.t

All messages sent are eventually received.

5.4 Discussion of Case Study

The fact that at least two related algorithms i... M1 I, ".] were published with
an incorrect deadlock avoidance schemes indicates the need for formal proofs of
such algorithms. The process of formally deriving the algorithm also led to a
simpler algorithm with fewer message types than in the original algorithms.
In addition to giving a corrected version of a previously published algorithm,
the example has been presented in order to illustrate the process of algorithm
derivation using refinement of mixed specifications. The first step was to give
a simple specification. The commands captured the basic (safety) behavior of
the nodes, while the properties described what additional constraints need to
be satisfied in order to satisfy the mutual exclusion requirement.
There are numerous algorithms for mutual exclusion. The next step, involved
characterizing the basic idea of the algorithm presented here-namely the notion
of information structures and the invariants describing the constraints on them.
M1 was derived from MO by strengthening guards on commands necessary to
maintain the invariants, and adding additional commands to allow progress. We
also chose at this point to refine the 'global' progress property (if u is hungry,
then it will eventually receive grants from all nodes in its request set) to a much
weaker property that involves the actions between pairs of nodes, i.e. if u is
















the minimal requester and needs a grant from v, then either u eventually gets
a grant from v, or another smaller request enters the system.
The next step involved adding communication channels and local variables.
Invariant properties that defined the meaning of the messages were added to
the specification, obtaining M2.
Finally, we made significant use of the UNITY proof theory to absorb the
safety properties of M2, make a small optimization, and replace the progress
properties with implementable ones, obtaining M3. Although this step required
a certain amount of trial and error to discover an adequate invariant, it was not
particularly difficult, the hardest part being handling the situation where rel and
req or grant and yield messages could be in the channel at the same time. More
effort was needed to write it in a reasonably non-redundant form for inclusion
in the paper than was needed to obtain one that sufficed for the proof.
To compare this development with other approaches, we notice that the main
development of the algorithm took place in the modifications of the command
section. The modifications were more intuitive than an equivalent development
strictly with UNITY properties would have been. An important kind of modifi-
cation was strengthening the guard of commands. With an approach based on
strict program transformation (with fair commands), this would not have been
possible since guard strengthening is only allowed in restricted circumstances.
In addition, the fair commands would have given us a final 'specification' that
requires that all nodes eventually become hungry, clearly not something that
should be required. Incorporating progress by encoding fairness requirements in
the commands, as is done in [Bac89], while theoretically nice, in practice would
have significantly complicated both the specifications themselves at all levels
and the proofs of refinement.


6 Conclusions

Mixed specifications have been proposed as a generalization of UNITY that al-
lows for more natural specifications and adds data refinement to the repertoire of
approaches one can take for reasoning about programs. The theoretical contri-
butions include a novel approach to the substitution axiom based on refinement.
Alternatively, one can view this work as a generalization of the refinement cal-
culus for reactive and concurrent programs. A non-trivial distributed algorithm
was developed to illustrate the approach.


References

[Bac88] R.J.R. Back. A calculus of refinements for program derivations. Ada
Inform atica, '-'. '.1.. 1.'-' 1988.
















[Bac89] R.J.R. Back. Refinement calculus, part ii: Parallel and reactive pro-
grams. In J.W. de Bakker, W.-P. de Roever, and G. Rozenberg, ed-
itors, Lecture Notes in Computer Science Volume 430, pages 67-93.
REX Workshop on Stepwise Refinement of Distributed Systems, 1989.

[BvW89] R.J.R. Back and J. von Wright. Refinement calculus, part i: Sequen-
tial nondeterministic programs. In J.W. de Bakker, W.-P. de Roever,
and G. Rozenberg, editors, Lecture Notes in Computer Science Vol-
ume 430, pages 42-66. REX Workshop on Stepwise Refinement of
Distributed Systems, 1989.

[BvW90] R.J.R. Back and J. von Wright. Duality in specification languages: A
lattice-theoretical approach. Acta Informatica, 27:583-625, 1990.

[BvW92] R.J.R. Back and J. von Wright. Combining angels, demons and
miracles in program specifications. Theoretical Computer Science,
100(2):365-383,june 1992.

[C('\I-] K. Mani Chandy and Jayadev Misra. Parallel Program Design: A
Foundation. Addison-Wesley, 1988.

[C("',.] K. Mani Chandy and Beverly A. Sanders. Predicate transformers
for reasoning about concurrent computation. Science of Computer
Programming, 1995.

[CU89] W. Chen and J.T. Udding. Towards a calculus of data refinement. In
J.L. van de Schnepscheut, editor, Lecture Notes in Computer Science
Volume 375, pages 197-218. International Conference on Mathematics
of Program Construction, 1989.

[DS90] Edsger W. Dijkstra and Carel S. Scholten. Predicate Calculus and
Program Semantics. Springer-Verlag, 1990.

[GC \I1] P.H.B. Gardiner and Carroll Morgan. Data refinement of predicate
transformers. Theoretical Computer Science, 87:143-162, 1991.

[CG 11..] P.H.B. Gardiner and Carroll Morgan. A single complete rule for data
refinement. Formal Aspects of Computing, ..' -382, 1993.

[Hes92] Wim H. Hesselink. Programs, Recursion, and Unbounded /I ..
Predicate Rransformer Semantics and Transformation Rules. Cam-
bridge tracts in theoretical computer science 27. Cambridge University
Press, 1992.

[Hoa72] C.A.R. Hoare. Proofs of correctness of data representations. Acta
Informatica, 1(4):271-281, 1972.
















[JKR89] C.S. Jutla, E. Knapp, and J.R. Rao. A predicate transformer approach
to semantics of parallel programs. In Proceeding of the 8th AC if
Symposium on Principles of Distributed Computing, 1989.

[Jon91] Bengt Jonsson. Simulations between specifications of distributed sys-
tems. In J.C. Baeten and J.F. Groote, editors, Lecture Notes in Com-
puter Science Volume 527, pages 346-360. CONCUR '91: Proceedings
of the 2nd International Conference on Concurrency Theory, 1991.

[Kna90] Edgar Knapp. A predicate tranformer for progress. Information Pro-
cessing Letters, 33, 1989/90.

[Lam78] Leslie Lamport. Time, clocks and ordering of events in distributed
systems. Communications of the AC i/, 21(7):558-565, july 1978.

[Lam94] Leslie Lamport. A temporal logic of actions. AC if Transactions on
Programming Languages and Systems, 16(3):872-923, 1994.

[Lyn89] Nancy A. Lynch. Multivalued possibilities mappings. In J.W.
de Bakker, W.-P. de Roever, and G. Rozenberg, editors, Lecture
Notes in Computer Science Volume 430, pages 519-544. REX Work-
shop on Stepwise Refinement of Distributed Systems, 1989.

\1I -] M. Maekawa. A \N algorithm for mutual exclusion in decentral-
ized systems. AC if Transactions on Computer Systems, 3(2):145-159,
May 1 I-,

[MG90] Carroll Morgan and P.H.B. Gardiner. Data refinement by calculation.
Acia Informatica, 27:481-503, 1990.

\11--'-' i] Jayadev Misra. Progress. unpublished manuscript, The University of
Texas at Austin, July 1992.

\1I-'iI-.] Jayadev Misra. Safety. unpublished manuscript, The University of
Texas at Austin, July 1992.

\I..i. ] Carroll C. Morgan. Data refinement by miracles. Information Pro-
cessing Letters, 26:243-246, january 1988.

[OL82] Susan Owicki and Leslie Lamport. Proving liveness properties of con-
current programs. AC if Transactions on Programming Language and
Systems, 4(3):455 1I', 1982.

[San87] Beverly A. Sanders. The information structure of distributed mu-
tual exclusion algorithms. AC if Transactions on Computer Systems,
5(3):284-299, August 1 I-.
















SI,',II] Beverly A. Sanders. Stepwise refinement of mixed specifications of
concurrent programs. In M. Broy and C.B. Jones, editors, Proceed-
ings of the IFIP Working Conference on Programming Concepts and
Methods, pages 1-25. Elsevier Science Publisheres B.V. (North Hol-
land), 1990.

i'il] Beverly Sanders. Eliminating the substitution axiom from UNITY
logic. Formal Aspects of Computing, 3(2), 1991.

S',,ii..] Ambuj K. Singh. Program refinement in fair transition systems. Acda
Informatica, 30(6):503-535, 1993.

[UK93] R. T. Udink and J.N. Kok. On the relation between unity properties
and sequences of states. In J.W. de Bakker, W.-P. de Roever, and
G. Rozenberg, editors, Lecture Notes in Computer Science Volume
666, pages 594-608. REX Workshop on Semantics: Foundations and
Applications, 1993.

[UK'i.] Rob T. Udink and Joost N. Kok. Impunity: Unity with procedures
and local variables. In Proceedings of the International Conference on
Mathematics of Program Construction, 1995. to appear.


A Appendix

We show that there exists a conjunctive predicate transformer f and an idem-
potent, weakening predicate transformer g such that

c sat (vars, init, f, g) = c sat (vars, init,f, g) (162)

First we construct f and show that (Vi : (Vq : f.q.ci = q.ci+,)) = (Vi : (Vq
f.q.ci = q.ci+l))
Let

R.(s, t) = (Vq : q E P(var) : f.q.s = q.t)

and note that (Vi : (Vq : f.q.ci = q.ci+l)) = (Vi : R.(ci, ci+,)). Now define

f.q.s = (t : t Eva, : R(s, t) = q.t).

Clearly, f is universally conjunctive in q. Let

R.(s, t) = (Vq : q E P(var) : f.q.s = q.t)

Next, we show that f < f.















f.q.s
{ definitions }
(Vt (Vr : f.r.s = r.t) q.r)

(Vt: (f.q.s = q.t) = q.t)

(Vt : f.q.s V q.t)

f.q.s


Now, it suffices to show R.(s, t) = R.(s, t). The proof is by a ping-pong argu-
ment.

R.(s,t)
{ definitions }
(Vq : (Vu : R(s, u) q.u) = q.t)

(Vq : (R(s, t) q.t) = q.t)

(Vq : R(s, t) V q.t)

R(s,t)
{ definition }
(Vq : f.q.s q.t)
< {f (Vq : f.q.s = q.t)

R.(s,t)


Now, we define g and show that

(Vi : (Vq: g.q.ci = (k : k > i: q.c.))) =
(Vi: (Vq : g.q.ci = (3k : k > i : q.cm)))

g is defined to be the closure of g, i.e. the strongest predicate transformer weaker
than g that is weakening and idempotent. With p indicating the strongest
fixpoint, this can be written as

g.q = px : g.x V q

or

g.q = (3a : hV.false)















where
ho.q= false,

hn+ = g.(hn V q),

ha.q= (3 : < a : hP.q).

Since g < g, we immediately have
(Vi : (Vq : g.q.c, = (3k : k > i : q.cm))) =
(Vi: (Vq : g.q.c, = (3k :k > i : q.cm))).
The other direction is shown using transfinite induction. Let Q.q.i = (3k : k
i : q.c,) and omit universal quantification over i and q.
Base
g.q.ci e Q.q.i

false = Q.q.i
{ definition }
h.q = Q.q.i

Step
(Vq : hn+l.q.ci = Q.q.i)
{ definition of hn+1
(Vq g:.(hn V q).Ci = Q.q.i)
{ predict calculus }
(Vq: g.(hn V q).ci = Q.(hn V q).i) A (Vk : (Vq: (hn V q).ck = Q.q.k))
{ predicate calculus }
(Vq: g.(hn V q).cj = Q.(hn V q).i) A (Vk : (Vq : hn.q.k = Q.q.k))
{ induction hypothesis }
(Vq g:.(.hn V q).c = Q.(hn+1 V q).i)
{ precicate caluclus }
(Vq : g.q.ci = Q.q.i)

Limit
(h.q.ci = Q.q.i)
{ definition of h }
(3P: < a : (hO.q).ck) Q.q.i)
{ predicate calculus }
(V: < a : (hO.q).Ck Q.q.i)
{ induction hypothesis }
true




University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs