Much care has been put into the design of the acts, and we have good reason to believe they are mostly correct. This should not keep us from scrutinizing them over and over again. A working implementation would certainly be the most Impressive proof of success. But for the time being we rely on fo r m a l checking methods The aim of this chapter is to fortify the reader’s trust into our design.
If there was a serious flaw in our acts, it would most likely lie in the most complex part of our design, namely the synchronisation of the actors by the protocol. We will therefore design a framework (a testbed) in which we can examine the message passing behaviour of actors. We will determine all the message passing
states for every actor; its message passing behaviour is, at every moment, mostly
determined by its current message passing state. The possible state transitions can be summed up instate transition tables, this will be illustrated by various examples The state transitions of a UDF, or any net of actors, can be elaborated from the transitions of its components Execution logs are of great help in modelling the actions of an actor, or of a not. This will finally be demonstrated by modelling the entire execution of the ISievej program.
As regards difficulty, a big difference must be made between the I COPY] act and all other acts (t beginning of 4.5). The ¡COPY! act is a great deal more complicated than all the other node acts, which makes checking the icdPY, act the most demanding part of this chapter. We will see that even a rather simple IcoFTl (viz. the twin outported one) has an impressive number of states This is why we have to continually look out for sim p lifica tion s which keep the number of states low; without them, matters are in danger of becoming unmanageable The correctness of the other acts is by comparison quite obvious, and we discuss them briefly before the IcopyI act.
V » 2
6.1 Th* Tastbed
In preparation for our discussion, let us introduce some terms which will play an Important role throughout this chapter. We intend to check the correct behaviour of
a node actor, and we achieve this by p la cin g the actor in a testbed ( en viron m en t)
which will confront the actor with all the situations permitted within the protocol (such as all possible sequences of requests and replies, see also [Fau82]).
Let • be the node actor under examination. Each outport of • is individually connected to a domander (labelled g, like "greed y "), and each inport of • is connected to the pertaining supplier (labelled p, like "param eter "). This entire setup
(g and e and p) is called a testbed for the actor e. The following Lucid graph
represents a testbed:
The actor e is, of course, in a state at every moment, and we shall see that some kind
outport. In our implementation, there is no queuing on the arc3 (all the queuing takes place in the [COPY] node actors) and the ports at both ends of an arc have thus the same state. The state of a demander or supplier is exactly the state of its p ort The state of the actor • and the state of the testbed are therefore one and the same
When talking about the message passing at an arbitrary actor port, we will go on using the terminology of superiors and in fe rio rs (The arrows in Lucid graphs point always from inferiors to superiors ) In the testbed, g can be superior and • inferior, or ■ can be superior and p inferior.
-I---1-
H---
| s u p e r io r ■ | *--- ► i n f e r i o r I I— ■ I I ... I ( ou tp ort s t a t e ) ( inport s t a t e ) - + + +■ + + H--- (-| derrander g | « — 1 node a c to r • + s u p p ile r p j ■i---1-
+
of sub—state (a message passing state) can be ascribed to each mport and to each
V - 3
6.2 Program Analysis
A proper mathematical proof of correctness (termination and partial correctness) would require us to analyse every act in depth, instruction by instruction. That task alone would double the size, and exceed the aims, of this thesis. Such a proof would certainly be meritable, but it has to be le ft to the future.
However, some techniques can be readily taken over from proofing, such as in va ria n ts and loop term in a tion conditions. We can indicate only the general approach (l.e. detailed rules will not be given); matters vary greatly among the acts. Most acts are utterly simple, which means there is very little to be analysed.
Most loops in our node acts are stsm a l, i.e. altogether without termination. Often, no memory is retained from one loop pass to the next, so there are no loop invariants to worry about. Almost every actor • is a m ediator between its demander S and its supplier p: usually, any message from g is propagated in some form to p, or vice versa. This message is either a request (message flow: g p) or a rep ly (p
g).
One can analyse how • transforms the message; one should check, in particular, that invariants are not violated For example, when • receives a request, the same daton index must be re—used in the propagated request (while some nodes introduce a fixed index offset); this is all very node sensitive5.3 M t m g t Passing Behaviour
In another check, we treat the actor like a black box, and examine merely what goes on at its inports and outports, its message passing behaviour If the black box behaves incorrectly, though, one has to take the lid off and put matters right.
The message passing behaviour of an actor can be described by a state tra n sitio n table, and such a table can reveal where the actor violates design criteria. Let us first took more closely at state transitions, and then recast the protocol into a form convenient for state transition tables
V - *
5.3.1 M t i u g i Passing Stats, and Stats Transitions
For an actor, each action can be viewed as a state transition, and all the permitted state transitions can be presented as a table (a relation maps the states to their permitted successor states). Such a table is very useful:
— It reveals the actions which the actor can perform, — It permits a study of concurrent actions,
— it enables us to check whether inports and outports adhere to the request protocol,
— It can be used to exercise a given implementation of the actor. The Implementation is correct if the actor can execute each of the listed transitions, and if it never steps outside the alternatives listed.
Such a table can be produced for any act: we will give examples for some node actors. We will see that the rule for the table generation corresponds closely to the act, both are similar pieces of code. Transition by transition, each table entry (the intended behaviour) can be compared with the true behaviour of the actor. This reveals unwanted state transitions in faulty acts It would oven be possible to do some of these checks automatically
State transitions can be n o n -d * t* r m in is tic , i.e. an actor can sometimes choose between a number of next states. Furthermore, there is always the extra choice of carrying out only pari of what is possible, or of even doing nothing (successor state being equal to the present state). Such transitions have obviously a delaying effect. The act design is such that the overall computation result (of the Lucid program) is deterministic even though the execution may be non—deterministic
Since we are only trying to model the message passing behaviour, we can often ignore those parts of the actor state which have no direct effect on that behaviour We call the resulting state the message passing state (which is a fu n c tio n of the total
V-5
state of the actor). As far as message passing is concerned, the choice o f successor state is narrowed down by:
(1) the present message passing state of the actor •, (2) the action of the demander(s) g.
(3) the action of the supplier (s)
p.
The message passing state of an actor is made up of the states of its outports, possibly an internal state, and the states of its inports. Different formats are used for the message passing state of the various node types: there is no universal pattern suitable for all actors. There is one general rule: in all message passing states, the state of each inport or outport is always expressed through a message label (t 5.3.2). An example message passing state is (explained in 5.3.1):
D l. .2. A
5.3.2 Protocol Execution and Massage Labels
In section 4 2 we have agreed on a universal protocol Every node actor port is at every moment in a particular state of protocol execution (a port state), and the protocol permits only select successor states. The port state is determined by the lost message which traversed the p ort The message passing partners have no "knowledge" of the interned state of one another. It is therefore appropriate to denote their states in a format which gives the p o rt states particular prominence If two ports are connects* by an arc their states are unavoidably identical. We abridge each port state into a single character, called a message label, according to:
N NULLIFY (r e q u e s t , flo w in g upstream g -» • -• p )
C
COMPUTEA ADVANCE
K ADVANCE, fin a l index "
V-5
state of the actor). As far as message passing is concerned, the choice of successor state is narrowed down by:
(X) the present message passing state of the actor e, (2) the action of the demander(s) a,
(3) the action of the supplier(s) p.
The message passing state of an actor is made up of the states of its outports, possibly an internal state, and the states of its inports. Different formats are used for the message passing state of the various node types; there is no universal pattern suitable fo r all actors. There is one general rule: in all message passing states, the state of each inport or outport is always expressed through a message label (t 5.3.2). An example message passing state is (explained in 5.5.1):
D l. .2. A
6.3.2 Protocol Execution and Massage Labels
In section 4.2 we have agreed on a universal protocol Every node actor port is at every moment in a particular state of protocol execution (a port state), and the protocol permits only select successor states. The port stats is determined by the last message which traversed the port. The message passing partners have no "knowledge" of the internal state of one another It is therefore appropriate to denote th eir states in a format which gives the p o rt states particular prominence If two ports are connected by an arc their states are unavoidably identical We abridge each port state into a single character, called a massage label, according to: