© katz, spring 2007 cs236368 formal specificationslecture-- lamport 1 lamport ’s state machines...

© Katz, Spring 2007CS236368 Formal Specifications Lecture-- Lamport 1

Lamport’s State Machines

Formal Specifications of Complex Systems

CS236368

Shmuel Katz

The Technion


Specifying Concurrent Modules

• Classic paper by Leslie Lamport, ACM TOPLAS, vol. 5, no. 2, 1983

• Texual, parametric state machine

• Insight on overlapping, interference

• For concrete program unit, like input/output interface, but reactive

• assumes sequential data structures


Open versus Closed systems

• A Closed system has all components inside the specification, and a simple interface to an Environment

• An Open system has “unknown” assignments, messages, events at any time. Much harder to specify and show correct, but sometimes necessary.

• When do operations take effect?


Overlapping Can Be Tricky

• Initially x = 0• Execute x := x+1 in parallel with x:= x+2.

• What are the possible results?

• The answer can depend on what is considered ‘atomic’

• Many systems today have multiple processes (sometimes with time sharing)


Shared Memory Concurrency

• Multiple processes that change the same variables (operate over the same state)

• Have to consider what happens DURING an implementation....input/output is not enough.

• New issues:> waiting,> deadlock,> mutual exclusion,> starvation


Basic set-up

• Have sets of atomic actions

• First part--for safety properties• Later--temporal logic for liveness

• Get values of a state from State Functions, that take the state to a value.

• x:S --> V and at(c) are state functions.• Since the domain is always the state, just

write f:R where R is the range


Parts of a Spec.

• State functions f1: R1, f2: R2, ...• Initial conditions I1, I2, ...• Properties P1, P2, ....

• If the initial state satisfies the initial conditions, all subsequent states satisfy the properties Pi, when examined through the state functions f j.

• If Pi is a regular logic predicate, asserts that it is an invariant of the system.


Other ways of writing Pi

• A leaves unchanged f when Q> A: a set of actions> f: a state function> Q: a predicate> Means: if a is in A, and Q(s), s---> s’ then f(s’) = f(s)

• TOP leaves unchanged stack> TOP is a set of actions, stack is a state function

• INREAR leaves unchanged front when ~empty


Allowed Changes

• allowed changes to g1 when Q1 g2 when Q2 A1: R1 --> S1 ..... Am: Rm --> Sm

> gi: state functions, Qi: predicates> Ai: set of actions, Ri: predicate> Si: binary function on s, s’ pairs

• for any a taking s to s’, if Qi(s) and gi(s’) =/= gi(s), then for some j, a is in Aj, Rj(s), and Sj(s, s’ )


Allowed Changes (cont.)

• “If it changes, it does so in one of these ways....”

• Does not force change--for safety only• Assume that the condition for activating is

made false by the change, so we won’t just keep repeating the same action.

• Use f and f’ instead of f(s) and f(s’)• Assume gj’ = gj if gj’ is not in Si• allowed changes to stack POP: | stack| > 0 --> stack = out’ stack’


Procedures and Parameter Passing (see handout)

• Modules with procedures• Can have several procedures active at

once, but only one copy of each.• Parameters are passed in a global variable

(on purpose to show problems)• SUB is in MOD, calls are from outside MOD• SUB.PAR : state function for the parameter• at(SUB) = control is at beginning of SUB• after(SUB) = control just after last of SUB• in(SUB) = control is in SUB (including at• the beginning, but NOT the exit point)


module SQ with sub SQUARE

• All of SUB with SQUARE substituted• state function val: Integer• at(SQUARE) ==> val = SQUARE.PAR

• after(SQUARE) ==> SQUARE.PAR = val2

• unchanged val when in(SQUARE)

• (Above are safety properties only-- need separate guarantee of progress/ liveness)


Summary on Lamport’s approach

• For Open Systems where unknown processes can change the system (see queue in handout)

• The notation restricts which changes are allowed, while still allowing concurrency

• The notation is only to restrict what is possible—so only relates to safety properties

• Liveness is added using Temporal Logic• This approach can be used to specify Fault

Tolerance—will see next…• “leaves unchanged” and “allowed changes” are

awkward, but typical for safely properties


Lamport (cont.): A Lossy Queue

• Exactly like a regular one, but with one more allowed change:

queue = Q --> queue’ < Q (could have written queue’ < queue) < means “ is a subsequence of”

• Problem: the liveness property of GET [] ( (in (GET) /\ |queue| > 0 => <> after(GET))is now too strong (can’t really implement)


A Compromise

• No liveness constraint on GET leads to a useless lossy queue.

• Always finishing if there is an element is too demanding.

• Suggested compromise:[](in(GET)/\ [] <> |queue| > 0 => <>after(GET))

• If the queue repeatedly is nonempty, eventually the GET will finish.


A Channel is a Lossy Queue

• Replace PUT by TMT (transmit)

• Replace GET by RCV (receive)

• The TMT protocol will be in one computer and the RCV in another, with the new allowed transition modeling the possible fault of losing a message in transmission.


A Key Property

• In a lossy queue, if we keep transmitting the same message, it will get through!

[](( [] <> in(TMT) /\ []( at(TMT) => TMT.PAR = msg) /\ [] <> in(RCV)) =>

after (RCV) /\ RCV.PAR = msg )

• Can’t be stuck in RCV, because then the queue must be empty, contradicting the liveness of TMT. Thus exit RCV repeatedly, and each time remove an element. Must get to msg eventually.....


Implementing Fault Tolerance

• A reliable channel: specified by original queue with SEND for PUT and RECEIVE for GET

• Problem: Implement a reliable channel by imposing a Communication Protocol on two lossy queues. (code given in the tirgul)

• Example here: alternating bit protocol• Sender module has SEND routine

activated by user, and uses MTMT and ARCV. Receive module has RECEIVE routine, uses MRCV and ATMT.


Hints to Understanding

• squeue has the values SENT that have not yet been moved across the lossy channel.

• rqueue has the values received after crossing the lossy channel, before RECEIVE operations remove them.

snum has the bit value currently being sent

rnum has the bit value currently being received on the other side.


Hints (continued)

• Keep sending the same (bit, value) pair until you get back an ACK with that bit, then switch your bit and start sending the new bit with the next value.

• When you get a pair with a new bit put the value in the local rqueue, switch your bit and send an ACK back. Ignore additional copies with the same bit you have, but send back more ACKs with your bit.

• Initially, the bits are different on each side.


The Mapping

• Key to understanding: queue == if snum =/= rnum then rqueue ^ squeue else rqueue ^ tail (squeue)

• The mapping changes whenever snum orrnum changes-- but the RESULT of the mapping will

stay the same! (check cases where that happens)

• SEND and RECEIVE change the queue• TMT and using the lossy implementation do NOT


Liveness of the queue

• Need to show that SEND and RECEIVE satisfy the usual queue liveness properties

• Therefore, need that elements move across the lossy queue, so squeue has room, and rqueue can provide elements when queue has room/ isn’t empty (resp.)

• Use reasoning by contradiction on the temporal properties.


Summary

• Can model faults as ‘possible changes’

• Temporal logic gives global liveness properties not expressed in other ways.

• Reasoning can be confusing, need care in choosing temporal assertions.

• Open systems are especially hard to specify and verify, so tools are needed.

© katz, spring 2007 cs236368 formal specificationslecture-- lamport 1 lamport ’s state machines...

Documents