Spin Model-Checking Exercise
Fall 2001

The Parking Garage

A parking garage has 500 spaces, two entries, and two exits.

An entrance consists of a ticket dispenser with a button, an electronic sign which displays either "space available" or "no space available", a gate that can be raised to let a car pass, and a sensor loop which senses that a car has passed through the gate. If the sign displays "no space available", then the gate should remain down, and pressing the ticket dispenser button has no effect. If the sign displays "space available", then pushing the button results in dispensing a ticket and raising the gate. The gate is lowered when the car passes over the sensor loop. For this exercise you may assume that, if a ticket is dispensed, the car will always enter the garage. (In real life we would have to consider the case of cars that pull out of the entry and leave without entering the garage.)

An exit consists of a ticket reader, a gate that opens when the ticket has been read, and a sensor loop. When a validated ticket is placed in the ticket reader, the gate raises to let the car pass. When the car passes over the sensor loop, the gate lowers again.

The number of cars in the garage is defined as the difference between the number of cars that have entered and the number of cars that have left. The number of cars in the garage cannot be negative, and it must never exceed the total number of spaces in the garage.

The Problem

The two entries and two exits must operate concurrently; it is not acceptable to "freeze" one of the entries or exits for the entire duration of a transaction at another entry or exit. However, there are potential race conditions. For example, if there is just one space available in the garage (499 spaces are occupied), only one car can be admitted to the garage. Your job is to design the synchronization structures of the garage in such a way that

• Concurrency between all physical actions (raising and lowering gates, physical movement of cars, etc) is preserved. You can have mutual exclusion between simple and presumably fast operations in the software.
• It is impossible for more than 500 cars to be in the garage at any time.
• The garage cannot ever deadlock.

To the extent possible, you should also try to achieve the following design goals:

• It is possible to fill all 500 parking slots. If you cannot fill all 500, try to maximize the number of parking slots that can be filled.
• Assuming every car that enters the garage eventually leaves the garage, any car that waits long enough at an entry will eventually be able to enter. (This rules out, for example, always giving precedence to one of the two entrances). This is called fairness, or freedom from starvation.
• The sign is a good predictor of what will happen if the button is pushed. If the sign says "space available", pushing the button really does result in a ticket being dispensed and the gate going up. If the sign says "no space available," it would be annoying to see cars entering through other entrance.

You may assume that, after the entry button is pressed and a ticket has been dispensed, a car will proceed through the entry gate. You may assume that, after a ticket is presented at the exit gate and the gate opens, a car will proceed through the exit gate. Do not assume more about the behavior of cars.

You may not introduce additional sensors or actuators in the garage. For example, you may not introduce sensors in the parking spaces themselves, in the tickets, or in the cars.

Unsolicited advice

This is an exercise that I have used before in seminars and classes. It is actually based on (badly written) requirements document that we have used in an inspections exercise, but I have modified it pretty heavily for use with Spin. Even so, you will need to modify it further --- and part of the point of this exercise is to get a feel for what it is like to "verify" a design of a real system, which initially means thinking very carefully about which details are absolutely essential and which can be discarded or idealized. The key to success is to start very, very small ... no, even smaller than that. Small. Tiny. Model nothing more than the essential concept of the design.

Think first, before you code. This is as important for building and verifying models as it is for writing "normal" programs, perhaps more so.

Make sure you understand what is wrong before you try to fix it. Random perturbations of your models will not help. (Maybe none of you need this advice ... but I have seen previous students, who would never consider "fixing" a program by making random mutations, suddenly switch into that mode for crafting a model.)

Don't be afraid to throw it away and start over.