1 / 77

Bridging the Gap Between Formal Methods and the Implementation Process

Bridging the Gap Between Formal Methods and the Implementation Process. Ecole Polytechnique Fédérale de Lausanne Claude Petitpierre ltiwww.epfl.ch/Bridge. A single language for specification, analysis and implementation. FORTE/PSTV'2000 Pisa. Contents. Basic concepts Real applications

mateo
Download Presentation

Bridging the Gap Between Formal Methods and the Implementation Process

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. Bridging the Gap Between Formal Methods and the Implementation Process Ecole Polytechnique Fédérale de LausanneClaude Petitpierreltiwww.epfl.ch/Bridge A single language for specification, analysis and implementation FORTE/PSTV'2000 Pisa

  2. Contents Basic concepts Real applications Analysis Miscellaneous Conclusion 1. General context 2. Synchronous objects 3. Channels versus synchronous calls 4. Creating concurrency primitives 5. Integrating events within synchronous objects 6. Client-server applications, CORBA 7. Sliding window protocol ( go back n ) 8. Consensus algorithm 9. Example of analysis (Dining Philosophers) 10. Random walker, transition relation 11. Inheritance, model of a component

  3. 1 General context Specification of the typical applications we want to address Definition of the choice statement Realization with Promela

  4. def P = C0 . in (0) . P + C1 . in (1) . P def N = out (x) . N def F = in (x) . F'(x) F'(x) = out (x) . F def 1.1 A toy application in CCS program module network driver GUI C0 C1 in (x) out (x) C0, C1: button clics x: identification of clicked button We need a choice + a rendezvous

  5. 1.2 Languages defining a select statement CSP CCS SPL PROMELA Occam Ada

  6. 1.3 Choice, select or alternate statement CHOICE (guard) offer <identification> <values / variables> OR (guard) accept <identification> <values / variables> OR (guard) timeout end CHOICE guard : the choice only considers the cases that have a guard with value true offer : either send into a channel or call a method (blocking) accept : receive from a channel or accept a call (blocking) identification : either the name of a channel or the name of a consumer or a producer

  7. 1.4 The rendezvous statement • channels -- Promela • <identification> channel name • <values> in the write statement • <variables> in the read statement • method calls -- our proposition • <identification> only in the call statement • <values / variables> in both the call and the accept

  8. def proctype P ( ) { do :: C0 ? z; in ! 0 :: C1 ? z; in ! 1 od } P = C0 . in (0) . P + C1 . in (1) . P proctype F ( ) { do :: in ? x ; out ! x od } proctype N ( ) { do :: out ? x od } 1.5 Promela program module network driver GUI in out C0 C1 chan in = [0] of {byte}; chan out = [0] of {byte};

  9. 1.6 Promela: guards with synchronous channels chan ch [3] = [0] of { byte } proctype A ( ) { byte guard, x; do :: ch[guard] ! x :: . . . od } proctype B ( ) { byte guard, x; do :: ch[2-guard] ? x :: . . . od } ch [0] ch [1] ch [2] Promela does not handle guards used with unbuffered channels, but the above construct solves the problem. A guard has a value in [0,1].

  10. 2 Synchronous calls Example of a synchronous object Select statement The toy program with synchronous objects Realization of the kernel

  11. 2.1 Synchronous objects and Java Synchronous objects: C++ (http://ltiwww.epfl.ch/sCxx) Java (http://ltiwww.epfl.ch/sJava) 1 1 Extension of Java with a concept of synchronous calls and a select. The select statement can be written with calls to a library, a pre-processor or a compiler (using the same library). All approaches use the original JVM.

  12. active class ActObj { void method () { . . . } run ( ) { for (;;) accept method; } } active class ActObj { void method () { . . . } run ( ) { for (;;) accept method; } } 2.2 Synchronous objects xx calls aco active class XX { ActObj aco = new ActObj(); run ( ) { for (;;) aco.method(); } }

  13. public active class Act { public void method (int var) { . . . } run ( ) { for (;;) { select { when (condition) act.actMethod (x) ; | | accept method ; | | waituntil (date) ; } } } } public active class Act { public void method (int var) { . . . } run ( ) { for (;;) { select { when (condition) act.actMethod (x) ; | | accept method ; | | waituntil (date) ; } } } } // synchronized method // (because it is a public method) body = a method running on a thread attached to the object 2.3 Form of a synchronous object public active class Act { public void method (int var) { . . . } run ( ) { for (;;) { select { when (condition) act.actMethod (x) ; | | accept method ; | | waituntil (date) ; } } } } public active class Act { public void method (int var) { . . . } run ( ) { for (;;) { select { when (condition) act.actMethod (x) ; | | accept method ; | | waituntil (date) ; } } } }

  14. active class P { run () { for (;;) { select { C0.pr() ; ff.in(0) ; || C1.pr() ; ff.in(1) ; } } } active class N { void out (byte x) { } run () { for (;;) { accept out; } } active class F { byte xx; void in (byte x) { xx = x; } run () { for (;;) { accept in; nn.out (xx); } } def P = C0 . in (0) . P + C1 . in (1) . P 2.4 The toy program with synchronous calls program module network driver GUI pp ff nn out in C0 C1

  15. for (;;) { list.add ( 0, call, actC, consMethodID ); list.add ( 1, accept, methodID ); list.add ( 2, waituntil, date ); switch ( kernelWait ( list ) ) { case 0: actC.consMethod (x) ; resume actC; break; case 1: // method has been called, continue break; case 2: // date has arrived ; } } for (;;) { list.add ( 0, call, actC, consMethodID ); list.add ( 1, accept, methodID ); list.add ( 2, waituntil, date ); switch ( kernelWait ( list ) ) { case 0: actC.consMethod (x) ; resume actC; break; case 1: // method has been called, continue break; case 2: // date has arrived ; } } kernel kernel 2.5 Realization of the kernel for (;;) { list.add ( 0, call, actC, consMethodID ); list.add ( 1, accept, methodID ); list.add ( 2, waituntil, date ); switch ( kernelWait ( list ) ) { // transmit list to the kernel and wait case 0: actC.consMethod (x) ; resume actC; break; case 1: // method has been called, continue break; case 2: // date has arrived ; } }

  16. 3 Channels versus synchronous object calls Communication characteristics of channels and synchronous calls Protocol stack Comparaison of asynchronous and synchronous communications n producers and n consumers with synchronous calls

  17. 3.1 Characteristics of the communication • Channels • channels = glue • n producers - n consumers • buffered: write non blocking • unbuffered (rendezvous) • selection: one channel in a set of channels, or one message in a channel, read/write action • pack data into messages • Synchronous calls • identification of the receiver • rendezvous • n producers - 1 consumer • selection between in/out calls channel: ch ch ! x ch ? x qq qq .in (x) accept in Selection statements must be capable to contain read and write statements

  18. user program user program 2 outgoing2 incoming calls 4 incoming calls pull data push data 2 outgoing 2 incoming calls at least 2 outgoing calls push data push data network driver network driver 3.2 Symmetrical select statements n+3 write / push data pull data / read n+2 n+1 n Synchronous communications: select statements with incoming-outgoing calls

  19. 3.3 Returning values with channels The error information must be returned through an extra channel channel A single channel for the return values The producers may receive the wrong return values return channel producers consumers channel One return channel per producer The identification of the channel must be sent with the message ret chan ret chan ret chan

  20. blocking if all processes do read ; write read write write read read write write read write read read write 3.4 Asynchronous channels do not avoid every deadlock

  21. 3.5 Channels versus synchronous communications blocking if all processes do read ; write or all do write ; read accept write write accept accept write

  22. 3.6 Scheduling of processes write || read write || read write An unbuffered channel cannot accumulate messages

  23. no deadlock select accept or write select write or accept 3.7 Channels versus synchronous communications potential deadlock read reply or write read write read or read reply When they run on a monoprocessor, synchronous systems are NOT more constrained than asynchronous systems !!

  24. 3.8 Handling n consumers Addressing the first consumer ready in a set of consumers select {forall (i: 1..n) consumers[i] . method(x) ; } producer consumers[]

  25. 3.9 Accepting from a particular producer accept method from producerX ; producerX producers consumer This construct is compatible with a select statement

  26. 3.10 Comparison between channels and calls • n producers -- n consumers • return values easier to get • method = integrated channel • no intermediate glue • parameters need not be stored in a message • object oriented

  27. 4 Creating standard elements with synchronous objects Realization of a semaphore Realization of a synchronous finite state machine

  28. 4.1 Two realizations of a semaphore (lock) active class Semaphore1 { void p ( ) { } void v ( ) { } run ( ) { for (;;) { accept p; accept v; } } } // Method p's execution is // allowed only when it is // enabled. A call to p can // be put in a select active class Semaphore2 { boolean s = free; void p ( ) { if (s != free) accept v; s = busy; } void v ( ) { s = free; } } // No body defined // Methods called atomically // The call to this p cannot // be used in a select !

  29. 4.2 Universal semaphore active class Semaphore { void wait ( ) { } void register (boolean on ) { store/delete caller address } run ( ) { for (;;) { // choose next user to release: XX select { accept register; | | when (ready) accept wait from XX; } } } } Use of the semaphore semaphore.register (on); select { semaphore.wait (); | | // await other event semaphore.register(off); } (can schedule readers/ writers with priorities, Hoare monitor...)

  30. 4.3 Realization of a synchronized finite state machine run ( ) { for (;;) { state0: accept myMethod ; state1: select { when (condition) act.actMethod (x) ; | | obj.method ; | | waituntil (date) ; } } } state0 myMethod state1 (condition) act_actMethod obj_method waituntil

  31. 4.4 Realization of a synchronized finite state machine run ( ) { for (;;) { state0: accept myMethod ; state1: select { when (condition) act.actMethod (x) ; | | obj.method ; | | waituntil (date) ; } } } state0 (condition) myMethod (!condition) myMethod state1: !condition state1: condition act_actMethod obj_method obj_method waituntil waituntil

  32. 5 Integrating events within synchronous objects Java event programming (Listeners) Handling stubs in parallel Handling devices with direct programming Synchronous GUI in Java

  33. 5.1 Event programming (callbacks) GUI button program = set of functions function 1 textField function 2 function 3 socket ? The sequence of GUI actions is decided by the person who clicks in the windows. It is sufficient for the simplest applications, but is very restrictive. Java's TCP sockets offer blocking calls. Their parameters include an optional timeout to handle long lasting calls

  34. public class GUI { . . . . textField = new JTextField(20); contentPane.add (textField); textField.addActionListener ( newActionListener ( ) { public void actionPerformed (ActionEvent e) { tempString = textField.getText ( ); applicationObject.operation (tempString); } } ); } 5.2 Java's listeners TextField textField = new JTextField(contentPane); contentPane.add (textField) ; tempString = textField.getText ( ); application operation

  35. 5.3 Getting the first response from two stubs stubs start thread user network get the results and kill the other stub The user must start two threads because it cannot read the two stubs in parallel. However, getting the results, and killing the other stub and its thread needs some thinking from the programmer. It does not correspond to a specification nor to a model.

  36. 5.4 Synchronous reading of two stubs stub1 = new Stub (hostname); stub2 = new Stub (hostname); stub1.post_getRec(x); // parameter transmission stub2.post_getRec(x); select { x = stub1.ready_getRec(x); stub2.cancel(); || x = stub2.ready_getRec(x); stub1.cancel(); } // asynchronous remote call // parallel wait

  37. 5.5 Programming with synchronous objects GUI button B.Pressed() application module textField select xt.read( ) soc.recv( ) socket This application can control the sequence of actions it must undertake. The devices offer synchronous entry points (method). Socket similar to Java's socket, but the synchronous socket can be put in a select. The timeout can be completely defined and handled by the caller !

  38. 5.6 Another view of synchronous objects TCP socket send ( ) recv ( ) GUI component checkButton ( ) getTextField ( ) getRecord ( ) All exchanges, from component to component or from a component to the environment are synchronous and thus easy to model.

  39. 6 Client-server applications, CORBA Synchronous stubs Deadlock in a client-server application Asynchronous/synchronous CORBA calls

  40. Client Client Server Server network stub skeleton 6.1 CORBA stubs and skeletons The stub offers the same interface as the server, but sends the parameters in a message to the server. The skeleton reproduces the original call to the server. This approach is very close to Java's RMI, but it is synchronous and can thus be put in a select statement.

  41. Remote : potential deadlock call call call call accept accept accept accept accept ? accept call accept return return call call network + proxies 6.2 Distributed systems with simultaneous client-server roles Local: no deadlock

  42. 1 either 2 2 getRec accepted or 2 3 : in both states, reception is enabled. 6.3 Avoiding the deadlock post_getRec post ready_getRec ready

  43. 6.4 A CORBA event queue CORBA EVENT QUEUE PUSH / PULL (user perspective) put / get get / put This approach makes it easy to build an event queue with push/pull modes and to use it without knowing when it will deliver an event.

  44. // signatures of methods (IDL) // control of methods public Record getRec ( ) { // marshal data request.sendRequest(); // unmarshal response return response; } public void post_getRec ( ) { // marshal } public Record ready_getRec () { // unmarshal response return response; } public Record getRec ( ) { // marshal data request.sendRequest(); // unmarshal response return response; } // Synchronous call public void run() { for (;;) { accept post_getRec; request.sendRequest(); accept ready_getRec; } } public void run() { for (;;) { accept getRec; } } public void run() { for (;;) { select { accept getRec; | | accept post_getRec; request.sendRequest(); accept ready_getRec; } } } public void post_getRec ( ) { // marshal } public Record ready_getRec () { // unmarshal response return response; } 6.6 Creation of an asynchronous CORBA stub

  45. 7 The sliding window protocol (go back n)

  46. 7.1 SWP : message exchanges Source Destination acknowledgement 1 message 0 acknowledgement 2 message 1 message 2 time

  47. 7.2 Sliding window protocol: system configuration User 2 User 1 Source Destination channels C2In C2Out C1Out C1In messages losses

  48. 7.3 SWP: data storage last middle first window 1 2 3 4 5 6 7 0 1 2 3 messages sent and acknowledged messages ready for sending future messages messages sent but not acknowledged Messages kept in a queue within the SWP layer

  49. 7.4 SWP: 4 events (rendezvous) handled by the emitter • Reception of a message from the user • Acceptance of a message by the network driver (in order to send it) • Timeout (one acknowled-gement expected) • Reception of an acknowled-gement from the network User 1 Source C2Out C1In

  50. middle first window 4 5 6 7 0 7.5 SWP program (beginning) for ( ; ; ) select { when ( window < WindowSize ) // a message from the user accept Write; window++ ; ULMessage.NS = NSend; // numbering NSend = ( NSend + 1 ) % WindowRange; Q.PutMessage ( ULMessage ); // save in local fifo || when ( Q.middle != NULL ) // a message is ready to be sent C1.In ( MakeACopy (Q.middle) ); Q.middle.date = now(); Q.middle = Q.middle.next; || . . .

More Related