Bridging the Gap Between Formal Methods and the Implementation Process

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
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
Basic concepts Real applications Analysis Mi
scellaneous Conclusion
3
1 General context
Specification of the typical applications we want
to address Definition of the choice
statement Realization with Promela
4
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 ltidentificationgt
ltvalues / variablesgt OR (guard)
accept ltidentificationgt ltvalues / variablesgt
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 ltidentificationgt
channel name ltvaluesgt
in the write statement ltvariablesgt
in the read statement method
calls -- our proposition ltidentificationgt
only in the call statement ltvalues /
variablesgt in both the call and the accept
8
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
chguard ! x . . . od
proctype B ( ) byte guard, x do
ch2-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.c
h/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
2.2 Synchronous objects
xx calls aco
active class XX ActObj aco new
ActObj() run ( ) for ()
aco.method()
13
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
2.4 The toy program with synchronous calls
program module
network driver
GUI
pp
ff
nn
in
out
C0 C1
15
2.5 Realization of the kernel
for () list.add ( 0, call, actC,
consMethod ID ) list.add ( 1,
accept, method ID ) 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
3.2 Symmetrical select statements
n3
write / push data
pull data / read
n2
n1
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
consumers
producers
channel
One return channel per producer The
identification of the channel must be sent
with the message
ret chan
ret chan
ret chan
20
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
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)
consumersi . method(x)
consumers
producer
25
3.9 Accepting from a particular producer
accept method from producerX
producerX
consumer
producers
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
5.2 Java's listeners
public class GUI . . . . textField
new JTextField(20) contentPane.add
(textField) textField.addActionListener (
new ActionListener ( )
public void actionPerformed (ActionEvent e)
tempString textField.getText (
) applicationObject.operation
(tempString) )
application operation
TextField textField new JTextField(contentPane)
contentPane.add (textField) tempString
textField.getText ( )
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
soc.recv( )
xt.read( )
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
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
6.2 Distributed systems with simultaneous
client-server roles
Local no deadlock
42
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
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
7.5 SWP program (beginning)
for ( ) select when ( window lt
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 .
. .
51
7.6 SWP program (end)
when ( Q.middle ! Q.first )
// at least 1 message is not
waituntil ( Q.first.date T1 )
// acknowledged Q.middle
Q.first LLMessage C2.Out ()
// get an acknowledgement
while ((Q.first ! NULL) (Q.first.NS !
LLMessage.NR)) window--
ackgedMsg Q.ExtractMessage ( ) //
delete acknowledged // middle has
been updated if needed //
messages
The receiver just accepts and acknowledges the
messages in sequence
52
8 Consensus algorithm
53
8.1 Consensus algorithm (Chandra and Toueg)
A group of processes exchange values and time
stamps through a communication medium that may be
very slow. After a number of exchanges, a
majority of the processes must converge toward a
common value, the consensus value. Each
participant possesses an asynchronous channel
(representing TCP channels) through which it
receives the messages sent by the other
participants. The algorithm can be described in
terms of arithmetic expressions, tests and data
exchanges. The complete program is available at
http//ltiwww.epfl.ch/sJava/newsourc
es/Consensus It maps almost exactly on the
original proposal written in a pseudo-language.
The synchronization semantics of our program is
easier to understand (and it is a program that
can be compiled and run). Reference T.D. Chandra
and S. Toueg, "Unreliable Failure Detectors for
Reliable Distributed Systems", Journal of the
ACM, Vol. 43, No. 2, March 1996, pp. 225-267.
54
8.2 Consensus algorithm
Structure of a participant
send_estimate
proposes and receives estimates
to the other channels
from the other channels
send_selected_estimate
send_reply
send_rbroadcast
receive_estimate
receive_selected_estimate
receive_rbroadcast
buffered channel i made of a synchronous object
send_rbroadcast
receives termination
receive_rbroadcast
a send pushes data, whereas a receive pulls them
55
8.3 Consensus algorithm
One of the receive statements that the algorithm
relies on indicates a condition in its
parameters receive_estimate (r_p, n/21,
msg_estimate) // receive at least n/21
messages As synchronous calls are not entered
before the method is ready (atomic execution),
the called object cannot obtain the value of n
before accepting the execution. This call must
thus be splitted into the two following calls
post_receive_estimate (r_p, n/21)
ready_receive_estimate (msg_estimate) It may
then happen that two post orders are received
without the ready call in between, but the extra
post needs just to update the stored
indication. We have checked the algorithm by
random walking through its state space (an
exhaustive verification would have exceeded the
memory limits). Note that we had to chose the
transitions with a non homogeneous probability to
find an error we had introduced in the
solution.
56
9 The Dining Philosophers

• A solution that uses only object calls (very OOP)
• with the potential deadlock
• without the deadlock
• Composition of the philosophers' FSM

57
9.1 The Dining Philosophers
58
9.2 The Dining Philosophers (with a potential
deadlock)
active class Fork int available public
void get() void put() run ()
for () accept get accept
put Fork forks new Fork5
59
9.3 FSMs representing the philosophers and the
forks
Fi.get
Fi1.get
delay
Fi
Pi''
Pi'
Pi
put
get
delay
F'i
Fi1.put
Pi'''
Fi.put
Fork i
Philosopher i
Composition of 2 philosophers and 2 forks
P1 P2 F1 F2
P'1P2F'1F2
P1P'2F1F'2
P"1P2 F'1F'2
P'1P'2F'1F'2
P1P"2F'1F'2
Deadlock !
60
9.4 The Dining Philosophers (without deadlock)
void please() forksi.get()
// forksi my fork void thankYou()
forksi.put() run() for ()
eatingTime now()random() think for
() select accept
please accept
thankYou waituntil
(eatingTime) break think

The forks may be passive now . . .
61
9.5 The Dining Philosophers (without deadlock)
. . . wantToEat for
() select
accept please
accept thankYou

when (forksi.available)
phil(i1)5.please()
break wantToEat
// put forks back and think again
m 0 wantToEat for
() select when
(m lt 1) accept
please m 1
accept thankYou
when
(forksi.available)
phil(i1)5.please()
break wantToEat //
put forks back and think again
62
9.6 FSM representing a philosopher with his
personal fork
please
delay
thinking
please
the philosopher has no fork
thankYou
thankYou
please
please
Pi1.please
thinking
eating
the philosopher has a fork
thankYou
delay
Pi1.thankYou
63
10 System analysis
Random walk Transition relation (Manna Pnueli)
64
10.1 Random walk

• The kernel must know how many tasks it must
  handle
• It waits for a request from each task
• It chooses a pair of matching
  incoming/outgoing calls (call/accept) or a
  timeout at random and resumes the corresponding
  objects
• It waits for the two tasks to make new
  requests
• The values of the timeouts are ignored

kernel
65
10.2 Transition relation
This communication through a synchronous channel
(in SPL)
as this synchronous call
66
10.3 Transition relations (Manna Pnueli)
Two processes in parallel
Transition relation associated with the
transition from to
67
11 Miscellaneous
Inheritance Multiple bodies Multiple rendezvous
(intersection of guard sets) Interface behavior
Interface definition A model for components
68
11.1 Inheritance
active class Unlimit int get ()
void put (int x) run () while ()
select when (! empty) accept
get accept put
active class Limit extends Unlimit int get ()
return super.get() void put (int x)
super.put(x) run () while ()
select accept get n--
when (nltN) accept put n
guard of get (! empty) AND
true guard of put true AND
(nltN)
Each class level creates its own thread (to
control its own methods). get and put are
redefined in the derived class. The set of true
guards of the resulting object is the
intersection of the sets of true guards defined
at each level.
69
11.2 Components
Examples of components operating systems,
plug-ins, software IC, UNIX pipes, CORBA, DCOM,
Javabeans Composition into a network Delivery
form binary, class, plug and play, deployed by a
customer Functional behavior pre-post
conditions, safety/liveness properties Interface
signature synchronization model IDL timing
indication provided by the body
70
Conclusion
A language as general as Java can be completed in
a simple way to become a kind of specification
language (which can be analyzed if it does not
contain complex structures) Synchronous objects
are to semaphores what structured program-ming
was to gotos Synchronous objects have an IDL
compatible interface combined with a
synchronization means, they are thus good
candidates for the role of components Many
problems related to distributed systems can be
analyzed with formal methods if they are
expressed with synchronous objects Programs based
on synchronous objects can be considered as the
inversion of event driven programs
71
References
C. Petitpierre, Synchronous C, a Language for
Interactive Applications, IEEE Computer,
September 1998, 65-72. C. Petitpierre,
Implementing Protocols with Synchronous Objects,
in ed. D. Avresky, Dependable Network Computing,
Kluwer, November 1999, pp. 109-140. C.
Petitpierre, A Case for Synchronous Objects in
Component-Bound Architectures, internal report,
http//ltiwww.epfl.ch/sJava/synch_java/descrip.ps
C. Petitpierre, sC Programmation
pseudo-parallèle orientée objets, PPUR Lausanne,
1998, 224 pages. http//lampwww.epfl.ch/zenger/j
aco/ (synchronous extension of
Java) http//ltiwww.epfl.ch/sJava http//ltiwww.
epfl.ch/sCxx
72
Annexe 1. Synchronous GUI with Java
public active class Display // GUI with a
thread . .
textField.addActionListener ( new
ActionListener() public void
actionPerformed (ActionEvent e)
field1Ready true
localThread.synch ( )
) public String readString () ps.s
textField.getText () .
. . (Could be
simplified it the library could be
rewritten). The event restarts the local thread,
which in turn accepts the external calls.A
single thread handles all calls to the Graphical
User Interface !
. (continuation)
. public void run () // thread
for () select
when (field1Ready) accept
readString field1Ready false
accept synch
accept write
// end of class Display
73
Annexe 2. Dataflow machine
put
put
put
get
74
Annexe 3.1. A program and the corresponding FSM
int x 1 int get () return x void put (int
y) x y run () while (true) A1
select accept get A2
accept put when (x
lt 2) waituntil (now() T1)
x

when (xlt2)
time-out
x
x1
x, A1
accept put
accept
get
x, A2
75
Annexe 3.2. The complementary program
int y 1 run () while (true) B1
y objA.get() while (true)
B2 select y
objA.get()
when (y gt 0) objA.put
(y-1) break B2 // exit the
inner loop
y1
y, B1
when (ygt0)
y objA.get()

objA.put(y-1)
y, B2
y objA.get()
76
Annexe 3.3. Composition of FSMs
when (xlt2)
time-out
x
x1
x, A1
accept put
accept
get
x, A2
x1 y1
x1, y1, A1, B1
when (xlt2)
get
yx
77
Annexe 3.4. Composition of the two previous FSMs
when (xlt2)
x1 y1 A1 B1
when (xlt2)
get
yx
x1 y1 A2 B2
x2 y1 A1 B1
get
yx
put xy-1
get
yx
x0 y1 A1 B1
x2 y2 A2 B2
put xy-1
get
yx
x1 y2 A1 B1
x0 y0 A2 B2
when (xlt2)
get
yx
x2 y2 A1 B1