© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 1 Lamport ’s State Machines Formal Specifications of Complex Systems CS Shmuel Katz The Technion titleBoth on mastertitleBoth on master

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 2 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

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 3 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?

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 4 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)

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 5 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

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 6 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

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 7 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.

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 8 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

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 9 Allowed Changes allowed changes to g1 when Q1 g2 when Q2 A1: R1 --> S 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’ )

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 10 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’

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 11 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)

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 12 module SQ with sub SQUARE All of SUB with SQUARE substituted state function val: Integer at(SQUARE) ==> val = SQUARE.PAR after(SQUARE) ==> SQUARE.PAR = val  2 unchanged val when in(SQUARE) (Above are safety properties only-- need separate guarantee of progress/ liveness)

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 13 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

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 14 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)

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 15 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.

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 16 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.

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 17 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.....

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 18 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.

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 19 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.

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 20 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.

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 21 The Mapping Key to understanding: queue == if snum =/= rnum then rqueue ^ squeue else rqueue ^ tail (squeue) The mapping changes whenever snum or rnum 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

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 22 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.

© Katz, Spring 2007 CS Formal SpecificationsLecture-- Lamport 23 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.