Weekly Note 5
Hand-In #4, Tuesday May 22 at noon (12:00)
This is the last and final hand-in.
The newly opened IMADA Tower (built as a replica of some nice tower
in a large French city) has been build directly on top of the SDU main
campus. The tower has an elevator system with six floors. A
university ground level 'U' floor, four regular floors '1', '2', '3',
and '4' with apartments and a penthouse professor floor 'P' with
apartments for old grumpy professors.
The elevator is powered with a new and very powerful Warp®
super motor that can move the elevator any number of floors
atomically / "in one go".
Elevator Call Buttons
On each floor there is an elevator call button which can be used to
call the elevator to that particular floor. Inside the elevator the
same buttons are available, i.e., the elevator can go to any of the
// FSP for an elevator call button
CallButton = (callButton -> CallButton).
If you prefer, you are allowed to implement a memory less call
button system, i.e., you do not have to remember previous button
The elevator has a maximum capacity of C=3 persons, which may never
be exceeded. To enable us to count the number of people in the
elevator and to ensure that at most C people are inside the elevator,
each floor has a two-way turnstile that can be blocked.
// FSP for the turnstiles
TURNSTILE = TURNSTILE[FALSE],
( lock -> TURNSTILE[TRUE]
| unlock -> TURNSTILE[FALSE]
|when (!locked) in -> TURNSTILE[locked]
| out -> TURNSTILE[locked]).
The Penthouse Professor Floor
Obviously professors prefer not to mix with other people
(in particular students).
Hence, a few modifications have been made to the elevator system:
- On the ground U floor professors have a special entrance and
exit (on the opposite side of the elevator than the normal
- Normal (non-professor) people can be assumed neither to use the
special professor entrance at the U floor nor do they dare to try to
get to the P floor.
- If a professor presses the call button on the professor floor or
the call button on the ground floor (at the professor entrance), the
elevator first clears itself for "normal" people and then the empty
elevator proceeds to immediately pick up the professor.
Many questions are probably underspecified. It is your job to
identify possibilities and make appropriate (and realistic) choices +
argue for them, e.g., you may choose there is exactly one person living on each of the apartment floors.
Feel free to rewrite and/or modify the FSP above.
- Read this very thoroughly, as it is likely to improve your final result.
- Model the (unsafe) ELEVATOR without a controller.
- Observe that too many people may walk into the elevator (i.e.,
causing the elevator to fall down).
- Observe that a professor may be forced to ride the elevator
with normal people (equally disastrous).
- Add a safety property, CAPACITY_EXCEEDED, formally verifying
that the capacity may be exceeded.
- Add a safety property, PROF_NORMAL_MIX, formally verifying
that a professor may be forced to share the elevator with
annoying normal people..
- Now add a controller to model a IMADA_ELEVATOR (such that the above
problems may no longer occur).
- Verify formally that the above problems may no longer occur
(with the controller constraining the behavior).
- Subsequently add a liveness property, LIVE_VIP, formally
verifying that a professor is always eventually permitted to enter
and leave his apartment; assuming the people always move.
- Make a structure diagram (excluding the above properties).
- Structure your model into an implementation. Which processes
should be implemented as threads/monitors? Give a simple UML
diagram of your implementation (at the same level of detail as,
e.g., Figure 4.2 in the book).
- Finally, implement the IMADA_ELEVATOR in Java. As usual you should
try to reuse the action names for method names to emphasize how your
FSP model and Java program correspond.
Discussion Section, Wednesday May 9 at 12:15 in U26
- [MK] 7.4.
- [MK] 8.2 - 8.3.
- Extend your Barrier implementation from Weekly
Note 4 to determine in which order waiting Java threads
regain monitor access, i.e., for some suitable N,
Does it make a difference, if each thread wakes the next using notify()
instead of waking all threads at once?
- Let N threads enter the barrier, before calling wait(), they should each
record their number in the line.
- The last thread (or an extra thread N+1) wakes everybody up.
- For each thread, record in which order they wake up.
- Extend the extended Barrier implementation from above such that to see
what happens if N threads are waiting (after calling wait()) and M other threads
are waiting "outside" to get initial access to the synchronization lock.