University of Oregon Computer & Information Science

CIS 607 - SPIN Exercise
Due 9 February 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.

What you must turn in

Turn in on paper:

• A written overview (1 to 2 pages) of your design solution. This should be at a level that would appear in a high-level design document, i.e., it explains the overall strategy rather than describing in detail the actions taken by each process. Include a clear explanation of the properties that your design achieves (e.g., if it guarantees fairness among the entrances, say so.)
• Promela source code of a model of your design. This should be copiously commented to explain why your model is an adequate representation of your design, or/and you may attach a separate document explaining your modeling strategy. Your Promela source code should also include any assertions used to verify properties.
• The output from a SPIN verification showing that your model is correct. If explanation is needed to understand the SPIN output, include it.

Turn in by email:

• Your Promela source code, with any notes (e.g., special options that must be set) to run it through SPIN.

Ground rules for collaboration and discussion

For this exercise you are allowed and encouraged to collaborate. Solutions may be produced by individuals or teams of 2. Teams may communicate. I suggest you use the February 2 class meeting to discuss progress and problems.

The Promela source code that you turn in must include prominent notice of any external sources and of collaboration. For example, if you arrived at your solution after discussing general strategies with Jill Dougherty, and Sam Peckinpah helped you understand some obscure feature of Promela, then your Promela source code should credit Jill and Sam for their help. If you based your solution partly on the pathfinder example that comes with Spin, then that should also be noted prominently. I am very strict about these rules --- omitting proper credit transforms allowed collaboration into plagiarism.

Unsolicited advice

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

Start small. Really small. Add incrementally to your model, little by little.

Make sure you understand what is wrong before you try to fix it. Random perturbations of your models will not help.

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