Differences between SPIN and CAVA

It has been established in the beginning of this section on Promela that there is no real and useful formal description of the language. For this reason we had to see the implementation in SPIN as the specification. For some reason or other, we had to deviate from those SPIN-specific specification. We claim, though, that those deviations are conservative: Any model which runs with CAVA also runs with SPIN and yields the same result. For models not using those unsupported constructs, we generate the very same number of states as SPIN does. An exception applies for largegotochains and when simultaneous termination of multiple processes is involved, as SPIN’s semantics is too vague here, i. e., it does not

5.2 Promela

specify whether those processes die at the same time or only one after the other in different visible states.

In the following, we describe the known differences between our formalization and what is described for SPINs implementation.

d_step The deterministic step d_stepis an alternative to atomic. Everything inside is collapsed into one visible change, also removing non-determinism. This construct is not supported by CAVA. Instead one should replaced_stepbyatomic, which yields the same semantics (the other direction does not hold), even though generating larger models.

Because CAVA already uses the C preprocessor, this replacement can be easily done by passing-D d_step=atomic.

runis a statement Following the Promela specification,runis “the only operator allowed inside expressions that can have a side effect” (from [48]). Of course, havingrun A()as a full-fledged expression would be a disaster (and what wouldrun A() + run B()express?).

Thus SPIN enforces some, again rather underspecified, restrictions. As the sole reason for this semantics is to get hold of the process ID of the spawned process (pid = run A()), for which there are also other measures, we omitted this feature and maderuna statement.

This also improves the formalization, for we now can assume all expression to be free of side-effects.

asserts do not abort If SPIN comes across a violated assertion, the model checking process aborts and a counter-example is printed. As our model checker is tailored towards getting an LTL property as input and take this as its sole responsibility, such behavior could not be implemented properly inside CAVA. As an alternative, we added the general atomic property, read: variable,__assert__which is available in each program. Hence, it is necessary to actively check this variable in the LTL formula if assertion violation should be paid attention to.

Other property specifications For the same reason given in the assertion case, property specifications besidesltlandassertare ignored. In the SPIN-world, a very widely used approach for specifiying properties are the never-claims. This is an additional process which expects a property that must not happen. LTL formulas are normally converted into such a never-claim by SPIN.

Types are bounded As described in the section on finiteness 5.2.4, all types are bounded.

While this does not deviate from the general SPIN behavior, the bounds can be different.

SPIN does not specify any explicit semantics here, but solely refers to the underlying C-compiler and its semantics. This might result in two models behaving differently on different systems when run with SPIN, while CAVA, due to the explicit bounds in the semantics, is not affected. Moreover, in CAVA we do not allow overflowing of values except for well-defined types like booleans⁷.

7We found one model while benchmarking which was wrongly specified. Due to an integer underflow, certain paths were never reached. This passed silently in SPIN.

Certain variable declarations SPIN has strange semantics when it comes to variable declarations. In earlier versions of SPIN, all variable declarations inside a process definition were evaluated implicitly as if they were placed at the top of the process definition. That is, their actual positions were irrevelant, though the order mattered. While this behavior has been removed, there are occurences where the position is not taken into account. For instance the following program yields 0, which is expected:

int i goto L;

i =5;

L: printf("%d", i)

On the other hand, the following yields 5, which is unexpected. An error might have been better:

goto L;

int i = 5;

L: printf("%d", i)

In CAVA, the latter version is not allowed and would result in an error “unknown variable i”.

typedef Thetypedefallows to specify larger structures in Promela models. While this is an important feature, we thought it not feasible to implement it correctly in CAVA, due to the rather complicated restrictions on them:

It is not possible to assign the value of a complete typedef object directly to another such object of the same type in a single assignment. A typedef object may be sent through a message channel as a unit provided that it contains no fields of type unsigned and no arrays of typedef’ed structures. A typedef object can also be used as a parameter in a run statement, but in this case it may not contain any arrays. (Source: [48])

Binary Operations and unsigned Currently, binary operations on integers are not sup-ported by CAVA, as is unsigned, which implements bit-fields. Using the native Word theories by Lochbihler [33] this should be possible to be implemented, though.

Remote References Remote references allow to access other processes’ internal variables, both from LTL properties and from processes itself. This has not been implemented in CAVA, because it seems rather obscure and might not be trivial to implement.

Ignored Constructs Various constructs likexr,xs, advanced variable scoping, priorities, and visibility of variables are ignored. This does not alter the behavior of the model, but is mostly used for creating more efficient models. Especially advanced variable scoping is also, again, very underspecified. For example, it seems like even though variables can be scoped, there must not be two different variables with the same name in one process but different scopes. Also, all constructs of theprint*family are ignored, as they are not expressible in SML.

5.2 Promela

100 200 300 400

10 20 30 40

Time in s (CAVA)

Timeins(SPIN)

Test case

Figure 5.2:G truebenchmark on 157 tests