Lamport ’s State Machines

1. Lamport’s State Machines title Both on master Shmuel Katz The Technion Formal Specifications of Complex Systems CS236368 Spring 2004

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 Larch interface, but reactive • assumes sequential data structures

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?

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)

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

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

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.

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

9. 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’ )

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’

11. Procedures and Parameter Passing • 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

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 • unchanged val when in(SQUARE) • (Above are safety properties only-- need separate guarantee of progress/ liveness)