1 / 23

Lamport ’s State Machines

Lamport ’s State Machines. title Both on master. Shmuel Katz The Technion. Formal Specifications of Complex Systems CS236368. Specifying Concurrent Modules. Classic paper by Leslie Lamport, ACM TOPLAS, vol. 5, no. 2, 1983 Texual, parametric state machine

kohl
Télécharger la présentation

Lamport ’s State Machines

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  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

  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 (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)

  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)

  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

  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)

  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.

  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.

  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.....

  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.

  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.

  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.

  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

  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.

  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.

More Related