SPIN VERIFICATION EXAMPLES AND EXERCISES

| # `SPIN VERIFICATION EXAMPLES AND EXERCISES` Included below are some verification exercises that can help you get acquainted with the Spin model checker. All examples used here are available as Promela files in the Examples directory of the Spin distribution. ## `0. Installing Spin` We will assume you are using the most recent version of Spin, which at the time of writing is Version 6.4.0. If Spin is not yet installed on your machine, do this (assuming a linux-like machine):
    	$ cd
    	$ wget http://spinroot.com/spin/Src/spin640.tar.gz
    	$ tar -xzvf spin640.tar.gz
    	$ cd Spin/Src6.4.0
    	$ make
    	$ cp spin /usr/local/bin	# on a Mac: cp spin /usr/bin
    	$ cd ../Examples/Exercises
    	$ spin -V	# make sure it's there
    	Spin Version 6.4.0 -- 19 September 2014
## `1. Evaluating Search Complexity` This first set of exercises is meant to give an indication of the nature of the state space explosion phenomenon, and how Spin deals with it. It consists of small problems that can be solved with Spin. At each step, it is best to first try to determine what should happen, write down your prediction, and only then perform the experiment with Spin, and explain the result. (Especially if it differs from what you thought would happen.) Answer each of the questions marked a) ... k), spending as much as you need to understand what really happens. a) How many reachable states do you predict will the following small Promela model generate?
    	init {	// file: ex_1a.pml
    		byte i	// initialized to 0 by default
    		do	// loop forever
    		:: i++	// a C-ism for i = i + 1
    		od
    	}
Try a simulation run of 514 steps:
    	$ spin -u514 -p -l ex_1a.pml	# print out local vars at every step
Notice what happens with the value of byte variable `i` on the 255-th increment (in step 511). Note: The first argument `-u514`, limits the similation to 514 steps. The second argument `-p` tells Spin to print some information about every step that it executes, and the third argument `-l` tells Spin to print also the value of all local variables whenever they change. You can see all options that Spin supports by executing:
    	$ spin --
i.e., using two dashes as the argument. b) Would the simulation terminate if you didn't limit the number of steps? c) The model allows for an infinite number of increments of variable i. Is this still a finite state model? Note: Spin converts the program-like model into a state machine. You can see this in the simulation sequence, where every increment ends up taking two steps, instead of one. The second step is the jump back to the start of the loop. When we do verification, where performance is important, Spin optimizes the statemachines a bit more, and it gets rid of that second step again. You can see the optimized state machine that Spin generates by executing:
    	$ spin -search -dump ex_1a.pml
d) Estimate the number of reachable states for this model. Is it finite? Will a verification run terminate? Try it as follows.
    	$ spin -search ex_1a.pml	# equivalently: spin -run ex_1a.pml
Explain the output and the number of states that is reported. The `-search` argument is a shorthand in Spin version 6.4 for a series of steps to perform a formal verification, that you can also execute one by one (but would only do in exceptional cases):
    	$ spin -a ex_1a.pml # generate a C verifier for the model in pan.c
    	$ cc -o pan pan.c   # compile it
    	$ ./pan             # execute it
Spin's `-search` argument separates arguments processed by Spin in interpreting the model itself (these would go before the `-search` argument) and arguments that are used to compile and run the verifier (these would go after the `-search` argument). In our example we needed no additional arguments of either type. e) What would happen if you had declared the variable to be of type `short` instead of `byte` ? What if you use a `bit` ? Try these with a verification run and explain the results. Note: A `bit` or `boolean` variable can only store two different values. As you noted above, a byte variable can store 256 possible values, and is unsigned. The datatype `short` is defined the same way as it is in the C programming language: it is a signed quantity of 16 bits. See the definition of the data ranges for all Promela types in the manual pages for Promela: here. Note that the ranges can be machine dependent, as they are in C. f) Predict how many reachable states there are for the following system, and write them down as a reachability tree.
    	#ifndef N
    	 #define N	2
    	#endif
    	init {	// file: ex_1f.pml
    		chan dummy = [N] of { byte } // a message channel of N slots
    		do
    		:: dummy!85    // send value  85 to the channel
    		:: dummy!170   // send value 170 to the channel
    		od
    	}
Note: All Spin models are preprocessed with the standard C preprocessor. This means that we can use include files and macro definitions. In this case, the macro N is defined to have the value 2, unless you define a different value on the command line when you invoke Spin. For instance, you can define N to be 4 by executing:
    	$ spin -DN=4 -m -search ex_1f.pml
You can check your prediction as follows. We're only interested in the size of the state space, not in problems that may be caused by blocking on a full channel, so we use the `-m` option to define that the sender of a message never blocks. (Messages sent to a full channel are then lost.)
    	$ spin -m -search ex_1f.pml	# use -m to ignore buffer overflow
Explain the result. Note: If you were brave enough to omit the `-m` argument, you've noticed that there are far fewer states. Spin will in this case report all invalid end-state errors it finds. That term is a nice euphemism for deadlock: a state from which no further progress is possible, but where the process(es) in the model have not all terminated. An invalid endstate does not always correspond to an actual deadlock. If it does not, we can label the state where a process is okay to stop with an `end-state` label. We can place one at the first `do` keyword in the model, for instance, and then you'd be free to omit the `-m` flag, since the verifier now knows that it is okay to block the init process at that point in the code. You should get the same number of reachable states as before:
    	init {
    		chan dummy = [N] of { byte } // a message channel of N slots
    	end:	do
    		:: dummy!85    // send value  85 to the channel
    		:: dummy!170   // send value 170 to the channel
    		od
    	}
g) What happens if you set N to 3, 4, 5, etc. ? Express the number of states as a function of N. Use your formula to calculate how many states there will be if you set N to 14 ? Check your prediction as follows.
    	$ spin -DN=14 -m -search ex_1f.pml
Set N to 20 and repeat the run.
    	$ spin -DN=20 -m -search ex_1f.pml
Consider the following metrics on this verification run:
    	T: the elapsed time for the run that is reported at the end
    	S: the number of states stored
    	G: the number of total number of states stored and matched
    	V: the State-vector size (the amount of memory needed to store one state)
Note: T measures only the time needed to perform the verification. It excludes the time needed for the generation and compilation of the verification code itself. (At higher settings for compiler optimization, and for more complexi models, this can introduce a notable time delay as well.) G counts not just new states visited in the search, but also states that were re-visited (matched), so it reflects more accurately how much work was done by the verifier. S/T (or G/T) gives you a measure for the efficiency of the verification process, or the rate at which reachable states are processed. Generally this rate will depend on a number of factors, including the size S, and, of course, the speed of your machine. For Spin this rate is typically in the range 105 to 106 states per second. We look at a few other factors that can influence performance below. S*V gives you the amount of memory that would be needed to store the full state space without compression. The statespace is not the only place where memory is used during the search (e.g., the stack also consumes memory) but it is typically the largest factor. h) The efficiency of a reachability analysis also depends critically on the state space storage algorithm that is used. By default, Spin uses a standard hash-table with linked lists to store states. To study the effect of the hash-table size on performance, repeat the last verification run with a very small hash table, for instance as follows:
    	$ spin -DN=20 -m -search -w12 ex_1f.pml
Note: runtime parameter `-w12` goes after the `-search` option, and the other parameters for parsing the model itself go before it. Explain the results. Hint: compare the number of hash conflicts that is reported for each run. Try different settings for the `-w` argument. Notice that the number of states stored does not change, but the number of hash-conflicts, and the runtime needed, does. i) How much memory would you need to do a verification run for our last example with N=24 ? Note: both the number of reachable states and the number of bytes per state goes up with N. Estimate that you would need about 42 bytes per state for N=24. Now assume that you only have 16 Megabyte of memory available to store the statespace. You likely have much more, but we're going for the dramatic effect here. 16 MB is 224 bytes, so we could store no more than 16,777,216 / 42 = 399,457, or about 399,000 reachable states in this much memory. Other parts of the verification consume some memory as well, so this is an upper-bound only. To find out the real number, try it as follows. In this command we limit the search to 16 MB plus a 1 MB margin, and we use a small hashtable size (`-w15`:
    	$ spin -DN=24 -m -search -DMEMLIM=17 -w15 ex_1f.pml
We use a small setting for the hash-table `-w15`, to avoid that the hash-table itself would dominate the memory requirements. The default size of the hash-table would exceed the memory limit we are imposing here. All arguments that follow a `-search` argument are passed by Spin to either the compiler or the runtime verifier. In this case we used both types of pass-thru options. All arguments that preceed the `-search` argument are processed by Spin itself as before. If the real statespace size is2(N+1)-1 states (33,554,431), what fraction of that statespace did you cover in your verification run? Is it more than 1%? j) Let's see if we can improve over that last result, without increasing the amount of memory. Perform a bitstate search with Spin, as follows.
    	$ spin -DN=24 -m -search -DMEMLIM=17 -bitstate ex_1f.pml
The default argument for `-w` gives us precisely the right size of the hash-array of 16 MB here. (The default is `-w27`). Compare the number of states stored with that of the earlier run. It should have increased to about 64% of the actual number that you calculated before: a significant increase. Note: a few things are worth pointing out here. First, the coverage of the bitstate run is significantly greater than that of the exhaustive run, but both used precisely the same amount of memory. This improves the accuracy of a verification, and improves our chances of finding errors, but it will generally deny us the certainty of a proof if no errors are found. We can improve our chances of finding errors even more if we repeat the run with different hash-functions. By changing hash-functions we can achieve that hash-conflicts (which now remain unresolved and lead to truncation of the search) appear in different places, meaning that a different sampling of the state space will result. Spin has 100 different hash-functions builtin. You can change the default of `-h1` to for instance `-h71` to get a different sampling of the statespace. One other things you can vary, to influence the sampling, is the number of bits that is set per state (i.e., the number of independent hash-functions that is used per state). You do so by specifying a `-k` argument. The default is `-k3`, which sets three bit-positions per state by using three independent hash-functions, but you can specify any other value greater than zero. k) The default setting for the `-w` argument in a bitstate search is `-w27`. This defines a bitstate hash-array size of 227 bits, which at 8 bits per byte equals 224 bytes, or 16 MB. In a bitstate search the `-w` argument does determine the maximum number of states that can be recorded in the bitstate hash-array. Repeat the run without the memory bound, and enable some compiler optimization while you're at it, as follows:
    	$ spin -DN=24 -m -search -O2 -bitstate -w29 ex_1f.pml
and perform some additional runs with different sizes of the bitstate array (different from the default of `-w27`). Notice how the coverage achieved is changing for smaller and larger hash-array sizes. You should be able to get pretty close to exhaustive coverage of the statespace with a `-w30` or `-w31` argument, using no more than about 128 MB or 256 MB (a small fraction of what an exhaustive search would consume). Note also if the rate at which states are explored is changing much. For added credit, check also how the performance changes if you compile with or without different levels of compiler optimization, e.g., `-O`, `-O2`, or `-O3`. ## `2. Verifying a Protocol` The figure below shows a protocol specification given by Bartlett et al. This figure appears as Figure 3c in the paper referenced, which introduced what became known as the alternating-bit protocol. It was originally designed to make it possible to transmit information reliably over noisy telephone lines with low-speed (e.g., 300 baud) modems. A Promela version of this protocol is shown below. State S1 is the initial state in process A and state S2 is the initial state in process B.
      1 mtype = { a0, a1, b0, b1, err } // file ex_2.pml
      2
      3 chan a2b = [0] of { mtype }	// a rendezvous channel for messages from A to B
      4 chan b2a = [0] of { mtype }	// a second channel for the reverse direction
      5
      6 active proctype A()
      7 {
      8 S1:	a2b!a1
      9 S2:	if
     10 	:: b2a?b1  -> goto S1
     11 	:: b2a?b0  -> goto S3
     12 	:: b2a?err -> goto S5
     13 	fi
     14 S3:	a2b!a1  -> goto S2
     15 S4:	b2a?err -> goto S5
     16 S5:	a2b!a0  -> goto S4
     17 }
     18
     19 active proctype B()
     20 {
     21 	goto S2
     22 S1:	b2a!b1
     23 S2:	if
     24 	:: a2b?a0  -> goto S3
     25 	:: a2b?a1  -> goto S1
     26 	:: a2b?err -> goto S5
     27 	fi
     28 S3:	b2a!b0 -> goto S2
     29 S4:	a2b?_  -> goto S1
     30 S5:	a2b!b0 -> goto S4
     31 }
a) Use a spin verification to see if there are any unreachable states. Explain the result. b) How would you modify the model to make all states reachable? Consider modeling unreliable channel behavior, by including message loss and/or message corruption as possible behaviors. You can do so by introducing an additional channel process, that shuttles messages from sender to receiver, or you can do so by adding an option at the sender to either send message correctly, or as an `err` message, to simulate corruption. Like this:
    	S1:	if
    		:: b2a!b1	// correct transmission
    		:: b2a!err	// model message corruption
    		fi
c) How could you extend the model to be able to prove the following property: "Every message fetched by A is received error-free at least once and accepted at most once by B." This problem is a little harder. Skip it if you're not already familiar with writing Promela specifications. Hint: you can add fields to the messages with data values. To do so you have to change the channel declarations. For instance, as follows:
    	chan a2b = [0] of { mtype, byte }
    	chan b2a = [0] of { mtype, byte }
where the send and receive operations now have two field of matching types. For instance:
    	a2b!a1(78)
You can find more hints about proving this type of property in the last problem in this set, below. ## `3. Verifying a Mutual Exclusion Algorithm` If two or more concurrent processes execute the same code and access the same data, there is a potential problem that they may overwrite each others results and corrupt the data. The mutual exclusion problem is the problem of restricting access to a critical section in the code to a single process at a time, assuming only the indivisibility of read and write instructions. The problem was first described by Edsger Dijkstra. In practical applications, the mutual exclusion problem is normally solved by using locks or semaphores. (The concept of a semaphore was also first proposed by Dijkstra.) Locks and semaphores in turn are typically implemented with special indivisible machine instructions for test and set or compare and swap operations. It is especially important to note that mutual exclusion algorithms that do not use any special machine instructions no longer work correctly on modern CPU architectures with out-of-order execution. On these machines (i.e., the machine your using now, no matter which brand it is) the problem can not be solved under the constraints that Dijkstra defined in 1965. Nonetheless, for mysterious reasons, mutual exclusion algorithms still remain popular as examples of the application of logic model checking. a) Dijkstra published a first solution to the problem (that worked on the CPUs from that time) in his 1965 paper. A year later a different author published an "improved" solution" in the same journal (Comm. of the ACM, Vol. 9, No. 1, p. 45). It is reproduced here as it was published (in pseudo Algol).
      1 Boolean array b(0;1) integer k, i, j,
      2 comment process i, with i either 0 or 1 and j = 1-i;
      3 C0:	b(i) := false;
      4 C1:	if k != i then begin
      5 C2:	if not (b(j) then go to C2;
      6 	else k := i; go to C1 end;
      7 	else critical section;
      8 	b(i) := true;
      9 	remainder of program;
     10 	go to C0;
     11 	end
Model this algorithm as a Spin model, and prove or disprove the correctness of the algorithm. You do not need to, and should not, consider out of order executions. If you get stuck, take a look at a sample solution in file ex_3a.pml -- and analyze it as follows:
    	$ spin -search ex_3a.pml
    	$ spin -p -replay ex_3a.pml
In this sample solution an LTL property is used to verify the algorithm. You can also verify this simple safety property with a plain assertion. For hints on how to do that, see the suggestion box at problem 3b below. For more suggestions for replaying counter-examples, or finding shorter alternative sequences, look for the suggestion box under problem 3c below. b) The mutual exclusion problem was popular as an intellectual challenge for a very long time. For an overview solution attempts up to roughly 1984, see Raynal or Lamport. An elegant solution was published by Peterson. In Promela the solution can be modeled as follows. The predefined Promela variable `_pid` contains the id of the running process: which in this case is either 0 or 1.
      1 bool flag[2]	// file: ex_3b.pml
      2 bool turn
      3
      4 active [2] proctype user()
      5 {
      6 	flag[_pid] = true
      7 	turn = _pid
      8 	(flag[1-_pid] == false || turn == 1-_pid)
      9
     10 crit: skip	// critical section
     11
     12 	flag[_pid] = false
     13 }
Verify Peterson's algorithm with Spin. A simple way to do the check is to count the number of processes that can reach the label `crit`. You can add a global variable `cnt`, and increment it before reaching the label, and decrement it afterwards. Now it is easy to perform the critical check, simply with an assertion. For instance:
    	 9       cnt++
    	10 crit: assert(cnt == 1)
    	11       cnt--
Additional questions: what data type should `cnt` have? Could it be a `bit`? Could it be an `int`? Should it? Could the variable `cnt` be declared locally instead of globally? Explain your answer. c) Far too many publications contained what later turned out to be faulty solutions to the mutual exclusion problem. In the sixties and seventies there were no model checkers to quickly find out whether or not a solution was sound. As an example, the next version of the algorithm was recommended by a computer manufacturer to a customer in the late eighties.
      1 byte cnt                                    // file ex_3c.pml
      2 byte x, y, z
      3
      4 active [2] proctype user()
      5 {	byte me = _pid+1			// 1 or 2
      6
      7 L1:	x = me
      8 	if
      9 	:: (y != 0 && y != me) -> goto L1	// try again
     10 	:: (y == 0 || y == me)
     11 	fi
     12 	z = me
     13 	if
     14 	:: (x != me)  -> goto L1		// try again
     15 	:: (x == me)
     16 	fi
     17 	y = me
     18 	if
     19 	:: (z != me) -> goto L1			// try again
     20 	:: (z == me)
     21 	fi					// success
     22 	cnt++
     23 	assert(cnt == 1)			// critical section
     24 	cnt--
     25 	goto L1					// Dijkstra wouldn't like this either
     26 }
First try to find a scenario that leads to the assertion violation by studying the algorithm. Next generate the counter-example with Spin. Assuming that you easily generated a counter-example (`spin -search ex_3c.pml` will do it), the next question you'll have is how to inspect it. You'll need the Spin flag `-replay` for this. The `-replay` argument tells spin to look for a counter-example trail that is store in a file with the same name as the Promela model, but with file extension `.trail`. You can try, for instance:
    	$ spin -replay ex_3c.pml
which will show you a final value for the global variable `cnt` of 2, but it doesn't show the steps leading to the assertion violation. To do so you will have to add some more options, telling Spin what to print at each step. For instance:
    	$ spin -p -replay ex_3c.pml
is far more informative. You'll also notice that the trail is longer than it would need to be. To get a shorter trail, you can try running the verification with an iterative shortening option `-i`. For instance
    	$ spin -search -i ex_3c.pml		# add runtime parameter -i
    	$ spin -p -replay ex_3c.pml
# -p goes before -replay This is still not the shortest possible trail. To get that, you can recompile Spin to force it to search for the shortest possible counter-example. For instance by using a breadth-first, instead of the default depth-first search, as follows:
    	$ spin -search -bfs ex_3c.pml		# use breadth-first search
    	$ spin -p -replay ex_3c.pml
You can also get the shortest counter-example with the default depth-first search, but now you have to tell the verifier to remember the length of execution sequences (which uses more memory) and use the iterative shortening method:
    	$ spin -search -i ex_3c.pml	# modified depth-first with shortening
    	$ spin -p -replay ex_3c.pml
## `4. Verifying Petri Nets` It is often easier to build a small Spin model and ask the model checker to verify it than it is to write or to check a thorough manual proof of correctness. Petri Nets are relatively easy to model as Promela verification models. For this exercise, consider the Petri Net model shown below, which first appeared as Figure 1 in Berthelot et al. A Spin model for this Petri net can be written as follows.
      1 #define Place	byte	// assume at most 255 tokens per place
      2                             // file ex_4.pml
      3 Place p1=1, p2, p3          // place p1 has an initial token
      4 Place p4=1, p5, p6          // place p4 has an initial token
      5
      6 #define inp1(x)	x>0 -> x--
      7 #define inp2(x,y)	x>0 && y>0 -> x--; y--
      8 #define out1(x)	x++
      9 #define out2(x,y)	x++; y++
     10
     11 init
     12 {
     13   do
     14   :: inp1(p1)    -> out1(p2)	// t1
     15   :: inp2(p2,p4) -> out1(p3)	// t2
     16   :: inp1(p3)    -> out2(p1,p4)	// t3
     17   :: inp1(p4)    -> out1(p5)	// t4
     18   :: inp2(p1,p5) -> out1(p6)	// t5
     19   :: inp1(p6)    -> out2(p4,p1)	// t6
     20   od
     21 }
The net was proven to be deadlock free in the paper referenced, with a manual reduction and proof technique. Verify the result with Spin. Explain the result in detail. ## `5. Veryfying a Process Scheduling Algorithm` The model below for implementing sleep and wakeup routines in a distributed operating systems kernel is based on Ruane's description. The model contains an error that can be detected as a fair non-progress cycle (use runtime options -l and -f). Check if the proposed fix by Ruane, indicated in the model, suffices to remove the problem.
      1 mtype = { Wakeme, Running }		// file ex_5.pml
      2
      3 bit	lk,	sleep_q
      4 bit	r_lock,	r_want
      5 mtype	State =	Running
      6
      7 active proctype client()
      8 {
      9 sleep:					// sleep routine
     10 	atomic { (lk == 0) -> lk = 1 }	// spinlock(&lk)
     11 	do				// while r->lock
     12 	:: (r_lock == 1) ->		// r->lock == 1
     13 		r_want = 1
     14 		State = Wakeme
     15 		lk = 0			// freelock(&lk)
     16 		(State == Running)	// wait for wakeup
     17 	:: else ->			// r->lock == 0
     18 		break
     19 	od;
     20 progress:
     21 	assert(r_lock == 0)		// should still be true
     22 	r_lock = 1			// consumed resource
     23 	lk = 0				// freelock(&lk)
     24 	goto sleep
     25 }
     26
     27 active proctype server()		// interrupt routine
     28 {
     29 wakeup:					// wakeup routine
     30 	r_lock = 0			// r->lock = 0
     31 	(lk == 0)			// waitlock(&lk)
     32 	if
     33 	:: r_want ->			// someone is sleeping
     34 		atomic {		// spinlock on sleep queue
     35 			(sleep_q == 0) -> sleep_q = 1
     36 		}
     37 		r_want = 0
     38 #ifdef PROPOSED_FIX
     39 		(lk == 0)		// waitlock(&lk)
     40 #endif
     41 		if
     42 		:: (State == Wakeme) ->
     43 			State = Running
     44 		:: else ->
     45 		fi;
     46 		sleep_q = 0
     47 	:: else ->
     48 	fi
     49 	goto wakeup
     50 }
To verify this model we need a few more Spin features than we have discussed so far. First, to allow the model checker to find non-progress cycles (infinite executions that fail to include at least one state labeled with a progress tag), we need to pass an different run argument to Spin. Like this:
    	$ spin -search -l -f ex_5.pml
Which, if an error is reported, can be followed with the replay command:
    	$ spin -p -replay ex_5.pml
The first command directs spin to perform the verification with a search for non-progress loops (`-l`), while restricting to fair loops (`-f`). Without going into too much detail, the counter-example that we would find if we omit the `-f` option could be classified as "unrealistic", because it ignores normal process scheduling rules that allow processes that are not blocked to eventually execute. This is reasonable finite progress criterion for non-blocked processes. By default though, the model checker will report all possible counter-examples, and not just the reasonable ones: it takes a demonic approach to finding errors. (Plus, just like in real life, restricting to reasonable behavior is usually somewhat more complex than not doing so...) ## `6. Verifying A Go-Back-N Sliding Window Protocol` This go-back-n sliding window protocol follows the description from Tanenbaum in 1989. The model below includes some annotations, with printf statements, to facilitate the interpretation of simulation trails.
      1 #define MaxSeq	3	 // file: ex_6.pml
      2 #define inc(x)	x = (x+1)%(MaxSeq+1)
      3
      4 mtype = { red, white, blue } // for Wolper's test
      5
      6 bool sent_r, sent_b		 // initialized to false
      7 bool received_r, received_b	 // initialized to false
      8
      9 chan q[2] = [MaxSeq] of { mtype, byte, byte }
     10 chan source = [0] of { mtype }
     11
     12 active [2] proctype p5()
     13 {	byte NextFrame, AckExp, FrameExp, r, s, nbuf, i
     14 	byte  frames[MaxSeq+1]
     15 	chan  inp, out
     16 	mtype ball
     17
     18 	inp = q[_pid]
     19 	out = q[1-_pid]
     20
     21 	do
     22 	:: nbuf < MaxSeq ->
     23 		nbuf++
     24 		if
     25 		:: _pid%2 -> source?ball
     26 		:: else
     27 		fi
     28 		frames[NextFrame] = ball
     29 		out!ball, NextFrame, (FrameExp + MaxSeq) % (MaxSeq + 1)
     30 		printf("MSC: nbuf: %d\n", nbuf)
     31 		inc(NextFrame)
     32 	:: inp?ball,r,s ->
     33 		if
     34 		:: r == FrameExp ->
     35 			printf("MSC: accept %e %d\n", ball, r)
     36 			if
     37 			:: !(_pid%2) && ball == red -> received_r = true
     38 			:: !(_pid%2) && ball == blue -> received_b = true
     39 			:: else
     40 			fi
     41 			inc(FrameExp)
     42 		:: else ->
     43 			printf("MSC: reject\n")
     44 		fi
     45 	 	do
     46 		:: ((AckExp <= s) && (s <  NextFrame)) ||
     47 		   ((AckExp <= s) && (NextFrame <  AckExp)) ||
     48 		   ((s <  NextFrame) && (NextFrame <  AckExp)) ->
     49 			nbuf--
     50 			printf("MSC: nbuf: %d\n", nbuf)
     51 			inc(AckExp)
     52 		:: else ->
     53 			printf("MSC: %d %d %d\n", AckExp, s, NextFrame)
     54 			break
     55 		od
     56 	:: timeout ->
     57 		NextFrame = AckExp
     58 		printf("MSC: timeout\n")
     59 		i = 1
     60 		do
     61 		:: i <= nbuf ->
     62 			if
     63 			:: _pid%2 -> ball = frames[NextFrame]
     64 			:: else
     65 			fi
     66 			out!ball, NextFrame, (FrameExp + MaxSeq) % (MaxSeq + 1)
     67 			inc(NextFrame)
     68 			i++
     69 		:: else ->
     70 			break
     71 		od
     72 	od
     73 }
     74
     75 active proctype Source()
     76 {
     77 	do
     78 	:: source!white
     79 	:: source!red ->
     80 		sent_r = true
     81 		break
     82 	od
     83 	do
     84 	:: source!white
     85 	:: source!blue ->
     86 		sent_b = true
     87 		break
     88 	od
     89 end:	do
     90 	:: source!white
     91 	od
     92 }
     93
     94 ltl p1 { (<> sent_r -> <> (received_r && !received_b)) }
Perform a simulation, to see approximately how the protocol executes, for instance as follows, limiting the number of steps to the first 200:
    	$ spin -u200 ex_6.pml
Notice that in this case, because of the printf statements in the model, we don't really need to add the `-p` to the simulator. The two processes named `p5` are printing messages to indicate key steps in their execution. To verify the model for safety properties (assertion violations or reachable invalid end-states) we can say:
    	$ spin -search ex_6.pml
The verifier will then warn us about a problem:
    	error: max search depth too small
The error notice says that the default search depth was not sufficient to perform a full search. To fix that we have to use a larger depth limit than the default (10,000 steps). There's also another change we may want to make at this step, e.g., to temporarily ignore the LTL claim in a first check. We can do so by using the compilation directive `-noclaim`. This leads to the following command line:
    	$ spin -search -O2 -noclaim -m100000 ex_6.pml
This gives us a first impression of the complexity of the search, which is still quite manageable, but requires a fair amount of memory. Next we want to verify that this protocol correctly transfers data, without loss or reordering. This type of verification can be simplified by making use of Wolper's data independence theorem. To do so, the protocol must be able to transfer at least three colored messages (balls). In our version of the model we made sure that only one process transmits the colored balls, while the other checks that they are accepted in the proper sequence. The return direction transmits only dummy balls of one single type `none`, which the other side accepts without check. The LTL property `p1` that we specified at the end of the file can be used to prove that every execution sequence where a red message is sent eventually contains a state where a red message is received, and in that state no blue message could have been received yet. This establishes that the blue message cannot overtake the red message, and the red message cannot be lost. The LTL property will be verified by default, unless you disable it with the -noclaim parameter. There's also only one LTL property in this case -- if there was more than one you'd have to choose the one to use in the verification, for instance as: `spin -O2 -search -ltl p1 -m100000 ex_6.pml` .
    	$ spin -search -O2 -m100000 ex_6.pml # leave the LTL property enabled
Notice that the search completes faster than before, requiring a smaller statespace to be explored, because we limited the verification to the specific problem of finding a counter-example to the LTL property. For that, not all possible behaviors are relevant. (I.e., we are exploring the intersection of program behavior and property behavior only.) ## `References` Bartlett, K.A., Scantlebury, R.A., and Wilkinson, P.T. `A note on reliable full-duplex transmission over half-duplex lines,' Comm. of the ACM, 1969, Vol. 12, No. 5, 260-265, Figure 3c. E.W. Dijkstra, `Solution to a problem in concurrent programming control,' Comm. of the ACM, 1965, Vol 8, No. 9, p. 569. M. Raynal, Algorithms for Mutual Exclusion, MIT Press, Cambridge, Mass., 1986, 107 pgs. (The 1986 edition is a translation from the original French version published in 1984.) L. Lamport, `The mutual exclusion problem -- parts I and II,' Journal of the ACM, Vol. 33, No. 2, April 1986, pp. 313-347. G.L. Peterson, `Myths about the mutual exclusion problem,' Inf. Proc. Letters, 1981, Vol. 12, No. 3, pp. 115-116. G. Berthelot, and R. Terrat, `Petri Net Theory for the correctness of protocols,' IEEE Trans. on Comm., Vol COM-30, No. 12, Dec. 1982, pp. 2497-2505. L.M. Ruane, `Process synchronization in the UTS kernel,' Computing Systems, (Usenix, Summer 1990), Vol. 3, No. 3, pp. 387--421. D. Dolev, M. Klawe, and M. Rodeh, `An O(n log n) unidirectional distributed algorithm for extrema finding in a circle,' Journal of Algorithms, Vol 3. (1982), pp. 245-260. M. Raynal, Distributed algorithms and protocols, John Wiley and Sons, New York, 1992. A. Tanenbaum, Computer Networks, 2nd Ed., Prentice Hall, Englewood Cliffs, NJ., 1989, p. 214, 232-233. P. Wolper, ``Specifying interesting properties of programs in propositional temporal logic,'' Proc. 13th ACM Symposium on Principles of Programming Languages, St. Petersburg Beach, Fla., January 1986, pp. 148-193.
Spin Online References ProMeLa Manual Pages ProMeLa Grammar Rules Spin HomePage |  | `(Page Updated: 19 September 2014)`