Lecture 4 Event Systems

Transcription

1 Lecture 4 Event Systems This lecture is based on work done with Mark Bickford. Marktoberdorf Summer School, 2003

2 Formal Methods One of the major research challenges faced by computer science is providing a technology for building highly reliable software systems that perform well and evolve economically to ever-higher reliability and better performance. One approach is using formal methods, tools based on logic. They are not widely adopted. There are several approaches to improving them: More fully automated tools type checkers, model checkers, decision procedures More effective interactive tools provers 2

3 Our Experience We have worked on distributed system verification for a decade, with Ken Birman s group at Cornell. We discovered that we have accumulated sufficient knowledge that we could participate in protocol design and development at the speed of the designers and programmers. 3

4 Abstract Network Model Media Net Resources Bandwidth Resources Bandwidth Measured Frame Rate Bandwidth Bandwidth Bandwidth Bandwidth Resources Bandwidth Bandwidth Contract Bandwidth Measured Frame Rate Bandwidth Resources Contract 4

5 Concurrency Models There is an enormous literature providing models for concurrent computation and distributed systems, e.g. Petri nets, process calculi, operational semantics, domain theories, machine models (IO Automata, message automata), model theory, etc. These models support several logics of processes, e.g. temporal logics, programming logics, etc. Our work has been based on variants of Nancy Lynch s IO Automata. We presented some results in this summer school in 1999, with Jason Hickey. 5

6 Stack Model SENDER LAYER Header RECEIVER LAYER LAYER LAYER LAYER LAYER LAYER LAYER LAYER FIFO Queues BOTTOM LAYER Protocol Stack NET BOTTOM LAYER Protocol Stack LAYER Event Message 6

7 Event Systems Abstraction Specification Language State Machines System Code 7

8 Event Systems Key Concepts Type E of events abstract Type Loc of loci of events or process identifiers Type Lnk of communication links There are two kinds of events: (1) local actions and (2) receives; each can also send on links Each receive event has a unique sender Events at any locus are totally ordered, and causal order relates events among loci 8

9 Example Two-Phase Handshake S R p pl, pl, { : () } E = e E loc e = p { : (,) } Snd = e E sends el nul p { : } Rcv = e E kind e is receive on l p 9

10 Communication Diagram S R e l 1 e ' l 2 r l 1 e '' 10

11 Distributed Systems A distributed system D will be a graph G whose nodes are processes and whose links are communication channels. P 1 P 5 P 2 P 4 P 3 We will treat processes abstractly in these lectures. In our verification work we use message automata and IO Automata at the nodes. We can also imagine other abstractions e.g. active objects as well as CML or Java programs. 11

12 Executions of Distributed Systems Executions of distributed systems are event systems in a natural way. Executions are typically indexed by time, and that can be discrete, say t? N. At each moment of time, a process at i is in a state, (, ) (, ) sit mlt action,, and the links are lists of tagged messages,. At each locus i and time t, there is an ai (, t ), taken. The action can be null, no state change, no receives, hence no sends. i.e. 12

13 Fair-Fifo Executions We assume executions are fair: channels are loss-less; and fifo: messages are received in the order sent. 1. Only the process at i can send messages on links originating at i. 2. A receive action at i must be on a link whose destination is i and whose message is at the head of the queue on that link. 3. There can be null actions that leave a state unchanged between t and t Every queue is examined infinitely often, and if it is nonempty, a message is delivered. 5. The precondition of every local action is examined infinitely often and if true the action is taken. 13

14 Event Systems of Fair-Fifo Executions If w is a fair-fifo execution of a distributed system D, we can define an event system from it, Ev w. The types from D. Loc, Lnk, Kind, Tag, Id are inherited The events E are the points < it, > locus i and time t, at which a non-null action, local or receive, occurre din w. 14

15 Specifying Protocols and Systems Function specification:? x : A.? y : B. R x, y ext f : A B Protocol specification is part of a system specification. x: System ProcessSpec x ext P i i We will focus on the ProcessSpec. 15

16 Axioms Axiom 1: For every event e which sends a list of messages on link l, we can find an event e' at the destination of l at which all messages sent are received.? e: E.? l : Lnk.? e': E.? e'': E. ( '') = ( '') ( '') = ' = '' ( ') = receive e e sender e link e l e e loc e dst l Axiom 2: The predecessor function at each locus is one-to-one. = ( ')? ee, ': E. loc e loc e' ( pred e = pred e e = e' ) 16

17 Axiom 3: Axioms The causal order is strongly well-founded. ( ) f : E N. ee, ': E. e < e' f e < f e'. Axiom 4: If e is not the first event at a locus, then its predecessor is at the same location. <.? e : E. first e loc pred e = loc e Axiom 5: If e is a receive event, then the locus of the sender is the source of the link of e.? e : E. receive ( e) loc ( sender ( e) ) = src ( link ( e) ). 17

18 Axioms Axiom 6: Messages on a link are received in the order sent. ( ) ( link ( e) = link ( e' )) ( ')? ee, ': E. rcv e rcv e' ( sender e < sender e ) e < e'. Axiom 7 : By convention, for any event except the first, to say that an observable x has a value v when event e happens at the locus of e is to say that x after the predecessor of e is v. ( x when e = x after pred ( e) )? e : E. first e? x : Id. 18

19 Deriving Algorithms and Protocols Sequential program derivation from a specification: Nuprl supports extraction. ( ) p: State State.? s : State. Rsps,? s : State.? s ': State. Rss, ' ext p 19

20 Refinements for Programs? x : A.? y : B. R x, y ext x. λ cut x, zg. ( x, z) ; l ( x) g ( x, z) l ( x) (, ) x : A? y : B. R x, y ext cut x, z. ; by cut L g ( x, z) 1. x : Az, : L? y : B. R x, y ext bydo g x z x ( g x z ) : Az, : L R x,, 2. x : A L ext by l ( x ) 20

21 ?D: System.? es : ES D. by Comp 1. D : System GLoc,, Lnk 1 2 Refinements for Systems pf1( D1, es1), pf2 ( D2, es 2) Res ext Comp : pf ( D, es ) es ES D R es ext D : System G Loc Lnk 1 (,, ) 2: ( 2) 2 ( es 2) ext pf2 ( D2, es2) es ES D R

22 Event Systems es of Distributed System D For an (abstract) distributed system D, say that es is an event system of D, es? ES D, if es is the event system Ev( w) of an execution w of D. 22

23 Deriving the Two-Phase Handshake We illustrate this process by deriving a protocol for the two-phase handshake from a proof that its specification is realizable. (), :. : e1 e2 SndSl,? r RcvSl, e1 < e2 e1 < r < e2 (), :., : e1 e2 SndRl,? r1 r2 RcvRl, e1 < e2 r1 < e1 < r2 < e2 23

24 Deriving Handshake 1 One way to achieve alternation of sends and receives at S is to introduce a and stipulate that S sends only when rdy is true. When a send on l occurs, rdy Lemma 1: is set to false. boolean variable rdy For any two processes SR,, and links l, l, ( 1) & ( 1), ( 2) & dst ( l2 ) = S,& rdy in Id, src l = S dst l = Rsrc l = R we can realize an event system with the property that initially rdy = true at S. Call the realizer for Lemma 1 ES

25 Deriving Handshake 2 Lemma 2: We can find a realizer that extends such that for any non-empty type T, Infinitely often the process at S will examine its precondition rdy = true. If rdy has not changed, then the send will occur, and rdy will be set to false. Otherwise, rdy must be false at t, so some event e' after e set it to false. ES? e': ES. e < e' (? v : T. ( rdy after e' = false sends ( e l) = l val v ) rdy when e = false) e: E. rdy when e = true Proof : Qed S ', 1,, '. Call the realizer for Lemma 2 ES

26 Deriving Handshake 3 Lemma 3: such that We can find a realizer that extends ES ( 1) e: E. sends el, nil rdy after e = false. S 2 Proof : We constrain the realizer of Lemma 2 to satisfy the condition val Qed that there are no actions that send on except for the one specified in Lemma 2. Call the realizer for Lemma 3 ES 3. l 1 frame with tag 26

27 Deriving Handshake 3 Lemma 4: such that We can find a realizer that extends ( 2) e: E. rcv el, rdy after e = true. S ES 3 Proof : We add to the process at 2 S a response to any receive action on l, namely this receive will set rdy Qed Call this realizer ES 4. to true. 27

28 Lemma 5: such that Deriving Handshake 4 We can find realizers that extend ES? S e: E. rcv el, e': E. e < e' sends el, nil S Proof : We add the frame condition that only a receive on reset of rdy to false can affect rdy. l 2 or Note, rdy after e=true by Lemma 4. Execution is fair, thus the precondition of the send will be checked infinitely often, hence after e. Only a reset can change rdy to false by the frame condition, and this happens only if the send on l 1 is executed. Thus there will be an event e after e such that the send is executed. Qed Call this realizer ES 5. 28

29 Theorem 1: Proof : Deriving Handshake 4 Let e, e be send events at S on link l. Suppose e < e By Lemma 3, rdy after e = false. The only event that can 1 set rdy to true is a receive event. the only way e < e is possible is that rdy when e after e Qed 1 Any realizer extending there must be a receive event. 2 ES 5 satisfies ( Sl ) e, e : Snd. e < e r : Rcv. e < r < e 1 2 Sl, 1 2, = true e2. Thus before and 29

30 Lamport s TLA + Specification 2003 EXTENDS Naturals VARIABLES val, rdy, ack { 01, } { 01, } TypeInvariant val? Data rdy? ack? UNCHANGED { 01, } Init val? Data rdy? ack = rdy Send rdy = ack val '? Data rdy ' = 1 rdy UNCHANGED < CONSTANT ack Rcv rdy ack ack ' = 1 ack Next Send Rv c Spec Init Next val, rdy < val, rdy, ack > Data > THEOREM Spec TypeInvariant 30