CSE 132 (Spring 2015)
Studio 4: Multiple Locks and Dining Philosophers
(Locks and Lox)

Review studio procedures, if necessary, before starting.

Some guidelines for this week's studio:


Get Acquainted (15 minutes)

  1. The software for this studio is organized into various packages by functionality. This should make navigating through the code easier.
  2. Make sure the runAll() method in Main is calling .run() on the new Threads, so that no concurrency is happening yet.
  3. Run the Philosophers' problem by running the StudioMain as a Java Application. It is in the studio4 package. Make sure you understand what you see in terms of the philsophers' behavior.
  4. Take a look at PhilViz and notice the correspondence between event names and colors. Spend a few minutes changing the colors that get shown when a Phil gets hungry.
  5. Add another state in the perform() of a Phil, so that it plays after studying. Pick a suitable color to show when the Phil is playing in PhilViz.
    • Be sure to use status("playing") so that its change in state is observed via the PropertyChangeSupport.
  6. If you have time and inclination, arrange for the Phil randomly to play or study (but not do both) after it has eaten.
  7. OK time for deadlock: in StudioMain, change .run() in runAll() to .start().
    Recall in Studio 3 you used the debugger to help understand the nature of deadlock:
    • Which locks does a Thread currently own?
    • For which locks is a Thread currently waiting?
    Run StudioMain under the debugger, and use the steps from Studio 3 to explain why there is deadlock.
  8. After using the debugger to understand deadlock, explain what you see to a TA.

Double Locks

The Phil object, when it performs, has to get two locks, one on each Chop.

  1. Based on what you learned in class today, you will develop a DoubleLock object that initially just captures the behavior of obtaining two locks but later is more clever and avoids deadlock:
  2. Open Phil in the editor.
  3. In the constructor, note the DoubleLock object that is constructed based on the existing LockPubs l1 and l2.
  4. Change perform, as directed by the comments, so that after being hungry, it uses the DoubleLock's lockInvoke method to run the eating Runnable.
  5. You should continue to see deadlock.
  6. Now modify DoubleLock so that deadlock is impossible, using Havender's algorithm as discussed in class.
    • What role does SingleLockInvokable's getUniqueID() play in this algorithm?
    • Why is hashCode() inadequate for ordering objects?
    • Take a look at System.identityHashCode(Object)
  7. Show a TA your code and run the progam to show it works without deadlock.

Multiple Locks (Puzzler)

If you are short on time, think about this one outside of Studio.

If two locks are good, then an arbitrary number might be better.

  1. Look at the studio4.puzzler package. The MultipleLock should implement LockInvokable, as follows:
      • Don't worry about deadlock yet, just be sure you hold all the locks.
      • Remember you can use helper methods if needed.
  2. Try out the MultLockTest as a JUnit test and make sure it passes.
  3. OK, now worry about deadlock: how do you make sure that use of your MultipleLock class never results in deadlock?

Demo

When you done with this studio, you must be cleared by the TA to receive credit.


Last name WUSTL Key Propagate?
(or your numeric ID) Do not propagate
e.g. Smith j.smith
1 Copy from 1 to all others
2 Copy from 2 to all others
3 Copy from 3 to all others
4 Copy from 4 to all others

TA: Password: