Peterson's mutual exclusion algorithm revisited

Science of

Computer Programming ELSEVIER

Science of Computer

Peterson’s

Programming

29 ( 1997) 327-334

mutual exclusion

algorithm

revisited

F.W. van der Sommen, W.H.J. Feijen, A.J.M. van Gasteren*

Received

IO February 1996; revised I5 July 1996 Communicated by M. Rem

Abstract A new derivation of Peterson’s well-known mutual exclusion algorithm is presented. The drrivation is driven by the formally stated requirements of Individual Progress, as opposed to the more traditional approach which starts from the requirement of Mutual Exclusion. The only formalisms used in the derivation are the predicate calculus and the theory of Owicki and Gries. No use is made of temporal logic. In particular, the so complicating oscillating behaviour of an u~uit-condition is fully absorbed by the use of a variant function. @ 1997 Elsevier Science B.V. Kqwds: Multiprogramming; Mutual Exclusion

Progress;

Variant function;

Program development;

Simplicity:

I. Introduction Multiprogramming, ficult

activity.

sequential

i.e. the formal

Our mastery

or functional

design

of parallel

of it has not nearly

programming,

as anybody

programs,

is still a very

dif-

the level we are used to in engaged in multiprogramming will

attained

confirm. The main bottleneck is related to the aspect called liveness or proyress. The other aspect, called partial correctness or scfet>l, has proved to be doable. Multiprogramming and sequential programming do, however, share the aspects of partial correctwxv and the latter being called terminutiorz in case of sequential programming. So. why is there such an enormous discrepancy in difficulty? The sequential programmer sees to termination by means of a variant or bound function. (This is a - say, integer -~ function that is increased by the computation

pro~qrexs,

and that is bounded from above.) In fact, most developments of sequential programs start by choosing the bound function and the operations increasing it, see [4.8]. ‘The question is whether such a strategy could work for multiprograms as well. This note

’ Corresponding author. 0167-6423/97/$17.00 @ 1997 Elsevier Science B.V. All rights reserved. PII SOl67-6423(97)00003-8

E: W van der Sommen et al. IScience of Computer Programming 29 (1997)

328

327-334

presents an encouraging case study, to wit a formal derivation of Peterson’s mutual exclusion algorithm, driven by formally stated progress requirements. In particular, the so complicating variant

oscillating

behaviour

of an await-condition, is fully absorbed

by a

function.

Remark.

Peterson’s

mutual

exclusion

algorithm

is the most beautiful

2-component

mutual exclusion algorithm that we know of. Almost every text or monograph on concurrency will deal with it. Nevertheless, in all treatments that we are aware of, progress of the algorithm is dealt with either operationally (see, for instance, [ 1, 11, 12]), or formally but tediously (see, for instance, [3,6, 13]), or not at all (see [2,7]). Hence, our choice for Peterson’s algorithm as a case study. End of Remark.

2. The problem of mutual exclusion The problem lem statement, follows. We are given is engaged in a

of mutual exclusion is widely known. We briefly recall the probfor reasons of completeness and as a stepping stone towards what two component programs, computation given by

Comp.p and Comp.q, respectively.

Comp.p

* [ ncs.p ; cs.p ] ) and Comp.q is engaged

in

* [ ncs.q ; cs.q ] . We shall refer to this system of computations as the computation proper. The two fragments cxp and cxq are given to always terminate; the two fragments ncs.p and r2cs.q may or may not terminate. Now the problem rithm (phrased

is to superimpose,

on the computation

in terms of fresh variables)

ME: cxp and cs.q are never executed IP:

proper, an additional

algo-

to the effect that simultaneously

a component that has terminated its ncs will start the execution of its cs within a finite number of steps of the entire system, and vice versa with the roles of ncs and cs interchanged.

Requirement ME - which is the requirement for Mutual Exclusion - potentially hampers the computation proper, in that a component’s transition from its ncs to its cs is not unconditional. Requirement IP - which is the requirement for Individual Progress - however demands that the computation proper should not be hampered indefinitely.

F W.

xln der Sonwnen et al. /Science oj’ Computer Programnling 29 (1997) 327--33-l

Thus, after the superposition, C0mp.p:

the components

329

may take the form

co1np. q: * [ ncxq

* [ ncxp

; rn try. q

; entry.p ; if x+

; if p -+ skip fi

skip fi

; L’,Y. q

; cs.p ; e.uit.p

es-it. q

;

1

Statement if x + skip fi captures the potential blocking It behaves like the better known do TX + skip od.

of Compp,

necessitated

by ME.

We shall refer to the added code as the mutual

exclusion algorithm, and we emphasize that it operates on a state space that is totally disjoint with the state space of the computation proper. In particular, the guards c( and ,8 can be influenced by the mutual exclusion

algorithm

3. Modelling

only.

individual progress

In this section we largely ignore the Mutual Exclusion requirement and focus on the aspect of Individual Progress. We try to formalize, from an operational viewpoint, what Individual Progress means for the multiprogram given above. In order to keep the design as simple as possible, we will strive for a solution in which the entry- and exit-fragments terminate by construction. (They will, indeed, turn out to consist of a number of assignment statements only.) As a result, the only way in which Comp.p can be prevented indefinitely from making progress is by its getting stuck in its if-statement if r + skip fi. We now identify the (three) possible scenarios for which if ct --f skip fi can fail to terminate. Note.

Here

we

wish

to emphasize

that

in

our

computational

model,

executing

if x--j skip fi boils down to repeatedly

evaluating M, potentially an unbounded number of times. until u is evaluated to true, in which case the if-statement terminates. So, the only way in which we can guarantee termination of an if-statement is by seeing to it that the rest of the system eventually End of Note. The three possible l

scenarios

makes the guard stably true.

are

Comp.q is also engaged in the execution of its if-statement while x and fl are false. This is a situation of total deadlock. Using an ad hoc notation, we preclude this danger by requiring that our solution satisfy inif.p A inif.q

=5 c1 V p

(1)

330

F. W. uzn der Sommen

et (11.IScience

(Here, in$p characterizes

of Computer

Programming

29 (1997) 327-334

the states where Conzp.p is executing

or about to execute

its if-statement.)

Comp.q is engaged in a nonterminating

execution

of its ncs while a has the value

false. (Recall that the value of (x cannot be changed by the computation preclude

proper.) We

this danger by requiring

inif.p A inncs.q * a . (Here, inncs.q characterizes its ncs.) For reasons

Va> the states where Comp.q is executing

of symmetry

inif.q A inncs.p *

between

the components,

or about to execute

we also require

/I

WI

situation is that each of Comp.q’s executions of ncs.q and if p + skip fi does terminate. Then, Comp.q might injinitely overtake Comp.p, viz. by an execution sequence in which CI oscillates between true and false an unbounded number of times, while Comp.p happens to evaluate a only in those states in which M is false. We preclude this danger by introducing a natural-valued variable I, operated The remaining

upon by the components

as follows

C0mp.p: * [ ncxp ; t:=O ; if a+ ; cs.p

C0mp.q: * [ ncs. q ; t:=t+ 1 ; if b----f skip fi

skip fi

; cs.q

1 and introducing

1 a natural parameter

in$pAt>N

N such that

+ u.

Pa)

Then, while Comp.p is engaged in the execution of its if-statement, Comp.q will establish the (stable!) truth of tl after a finite number of executions of its loop body. Thus, the oscillations on z are only possible as long as the hound function t is not yet large enough. By requiring (3a). we can completely forget about the phenomenon of an oscillating guard. For reasons of symmetry, we also introduce variable s, natural parameter M, choose our components

to have the form

C0nip.p: * [ ncxp

C0mp.q: * [ ncs.q

; s,t:=s+ l,o ; if x--* skip fi ; cxp

; t,s:=t+ 1,o ; if a -skip fi ; cs.q

1

1

and insist on

inijlq A s>M

+ p

(3b) *

* *

F. W wz cler Sommen et ul. IScieuce of Computer Programming 29 (19971 327-334

331

Here our operational parlance comes to an end. Its only purpose was to get across that the conditions (l)-(3) for guaranteeing Individual Progress are “sweetly reasonable”. ’ One may argue or even complain adopted, but that is a separate concern. executions

and take (l)-(3)

a mutual exclusion

about the computational

In any case, we from now onwards forget about

as our point of departure

algorithm

model that we have

satisfying

towards

a formal derivation

of

ME and IP.

Of course, ( 1 )-( 3) are vacuously satisfied by taking x and [j both equal to true. but we have to bear in mind that requirement ME demands strong values for c( and fi (e.g. both equal to false would be fine). So we have to be a little more careful and find out a permissible spectrum for the guards x and fl.

4. Towards an implementation Finding a permissible spectrum for ;( and fl means that we have to solve ( I )-( 3 ) for a and fi. We repeat these equations, combining (2a) and (Sa) into (5a), and (2b) and (3b) into (5b).

iniJ:p A (inncs.q v t>N) in$q

A (inncs.p

V s>M)

=+ !x

(5a)

fl

(5b)

*

As we already alluded to before, the requirement of Mutual Exclusion is best served with strong guards (x and b. Equation (5a) tells us what rx can be at strongest. and (5b) does the same for /I. But what about (4)? We now try to prove (4), in order to find out what, besides (5a) and (5b), is needed for (4) to hold: XVg t

{(5a)

and

(5b))

(inijlp A (inncs.q V t>N)) -

t>N

{from

the antecedent

(iniJq

A (inncs.p V s>M))

of (4) : inzfip A inif. q}

{from the antecedent inncs.q V t >N V inncsp

z-

V

V s > M

of (4): in$p

;

from the structure

of Conzp.p, therefore.

and, by symmetry

also +nncs.q}

~inncs.p

,

v s>M.

So what is needed in addition to (5 ) is the invariance of t > N V s > M. But here we remember that we are still free to choose values for the parameters M and N. and for ’ Idiom added to CS-terminology

by Joseph E. Stoy

E W. uan der Sommen et al. IScience of Computer Programming 29 (1997)

332

reasons of simplicity suitable

we shall use that freedom. The multiprogram

initial values of s and t, the invariance

PO: Ods

327-334

as is, grants us, for

of

A O
and of PI:

s>O~t>O,

and, therefore,

s>o v

also of

t>o.

As a result, with the choice A4, N =O, 0, (4) is fully implied are freed from (4) and left with (5). Equations (5) give us the spectra

by (5). And, thus, we

for CI and p that we were after. Now,

if this

design is to lead to a correct solution of our mutual exclusion problem at all, we must investigate the strongest possible choice for cc and p. For LX,the strongest possible choice is, see (5a) for N = 0,

inif.p A (inncs.q V t>O) but because, by definition, inzf.p is a correct precondition omit this conjunct. Thus, we arrive at

of if CI-+ skip fi, we can

CIz inncs.q V t >O and, symmetrically,

p e inncs.p V s>O. In the next section,

we investigate

whether

these choices

indeed

guarantee

Mutual

Exclusion.

5. Peterson’s algorithm First, we introduce variables x.p and x.q to eliminate inncs.p and inncs.q. That is, we shall adopt the encodings

x.p E inncs.p

and

the “thought

expressions”

x.q E inncs.q ,

and adjust the components accordingly. Second, we observe that the interest in the integers s and t is only binary - their being positive or not -. Furthermore, by PI, they are not positive simultaneously. Therefore, we can replace the two of them by a single two-valued variable u. We propose the coordinate transformation

v=p

E s>O

and

u=q

E t>O.

F. W. oan der Sommen et al. IScience of Computer Progrumming 29 (1997) 327--334

And, thus, the next (and final) version Pre :

tl=pVtl=q

and

C0mp.p: * [ ncs.p ; x.p :=false ; v:=p ; if x.q V v=q~skip

of our multiprogram

333

becomes

x.pAx.q C0wzp.q: * [ ncs,q ; x.q := false ; [‘:zz 4 ; if x.p V c=pakip

fi

fi

; cs.p ; x.p := true

; cs.q ; x.4 I==true

1

1

And . . this is Peterson’s algorithm! We therefore abstain from showing that it meets the requirement of Mutual Exclusion: these proofs, which are readily given using the theory of Owicki and Gries [5, lo], abound in the established literature.

6. A final remark Over the past few years we have exercised on and gained experience in the formal derivation of multiprograms. A first account of this can be found in [9]. In doing so, our guiding principle was that the concerns of partial correctness (safety) and progress had to be dealt with separately. But now the question arises which of the concerns to focus on first. In our experiments so far, our designs were mainly led by the care for partial correctness (mostly leaving us with awkward a posteriori proofs of progress). In this note, we let ourselves be guided by progress requirements in the first place. This latter approach is - in principle - the fundamentally better one, as we shall now try to explain. In most synchronization tasks, the guarded skip (the awlait-statement) is the trouble spot: it is needed for the synchronization or partial correctness, but at the same time it endangers

progress.

However,

there is a theorem

(easily

shown)

saying that strength-

ening a guard of a guarded skip does not impair the partial correctness of the design (see [7,9]), whereas there is no theorem stating that weakening a guard of a guarded skip does not impair progress - counterexamples exist -. So, if we design our multiprograms by focussing on partial correctness, it need not be a good strategy to choose guards as weak as possible - thinking that this might be beneficial for progress -. But if we design them, led by progress requirements, partial correctness is best served by choosing the guards as strong as possible.

Acknowledgements We are indebted to the members of the ETAC (Eindhoven Tuesday Afternoon Club), in particular to Lex Bijlsma, for firing their comments at us. We are also grateful for

E K

334

remarks

t’an der Sommen et al. IScience of’ Computer Programming 29 (1997)

made by F.B. Schneider

that a next challenge sophisticated,

and an anonymous

is to apply the technique

327-334

referee. With the latter we agree

illustrated

here to more,

and more

examples.

References [I ] [2] [3] [4] [5] [6] [7] [8] [9] [lo] [l l] [12] [ 131

G.R. Anderson. Concurrent Programming: Principles and Practice, Addison-Wesley, Amsterdam, 1991. K.R. Apt, E.-R. Olderog, Verification of Sequential and Concurrent Programs, Springer, Berlin, 1991. K.M. Chandy, J. Misra, Parallel Program Design: A Foundation, Addison-Wesley, Amsterdam, 1988. E.W. Dijkstra, A Discipline of Programming, Prentice-Hall. Englewood Cliffs, NJ, 1976. E.W. Dijkstra, A personal summary of the Gries-Owicki Theory, in: Selected Writings on Computing: A Personal Perspective, Springer, New York. 1982. E.A. Emerson, Temporal and modal logic, in: J. van Leeuwen (Ed.), Handbook of Theoretical Computer Science, Vol. B, Elsevier, Amsterdam, 1990, pp. 995-1072. W.H.J. Feijen, Exercises in formula manipulation, in: E.W. Dijkstra (Ed.), Formal Development of Programs and Proofs, Addison-Wesley, Amsterdam, 1990, pp. 139-I 58. D. Gries, The Science of Programming, Springer, New York, 1981. P.D. Moerland, Exercises in multiprogramming, Computing Science Notes 93/07, Department of Computing Science, Eindhoven University of Technology, 1993. S. Owicki, D. Gries. An axiomatic proof technique for parallel programs I, Acta Inform. 6 (1976) 3 19-340. G.L. Peterson, Myths about the mutual exclusion problem, Inform, Process. Lett. 12 (1981) 115-I 16. M. Raynal, Algorithms for Mutual Exclusion, North Oxford Academic, London, 1986. F.B. Schneider, Notes on proof outline logic, in: M. Broy (Ed.), Deductive Program Design. Proceedings of the NATO Advanced Study Institute on Deductive Program Design. Springer, New York, 1996.