[SDU Logo]   Dept. of Mathematics and Computer Science
University of Southern Denmark Phone/Email Directory | Maps

 DM519 - 2012
Weekly Notes


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 six floors.

// 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 presses.


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], TURNSTILE[locked:B] = ( 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 entrance).
  • 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.


  1. Read this very thoroughly, as it is likely to improve your final result.
  2. 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..
  3. 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.
  4. Make a structure diagram (excluding the above properties).
  5. 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).
  6. 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

  1. [MK] 7.4.
  2. [MK] 8.2 - 8.3.
  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,
    1. Let N threads enter the barrier, before calling wait(), they should each record their number in the line.
    2. The last thread (or an extra thread N+1) wakes everybody up.
    3. For each thread, record in which order they wake up.
    Does it make a difference, if each thread wakes the next using notify() instead of waking all threads at once?
  4. 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.