CSE 132 (Spring 2011)
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 top 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.
    • In class, somebody asked about a full state, so that the Philosopher doesn't still appear to be eating while letting go of the chopsticks.

      In lecture, I mistakenly added the code to the wrong constructor. I took that constructor out of PhilViz and now you'll see the philosophers get full.

    • 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().
  8. Run the program a few times and explain what you see to a TA.

Double Locks

The Phil object, when it perform, 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 arbitarary 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. Modify MultipleLock so that its lockInvoke obtains a lock on each of the things before running the Runnable.
    A helper method may be useful.
  4. OK, now worry about deadlock: how do you make sure that use of your MultipleLock class never results in deadlock?
When you done with this studio, you must be cleared by the TA to receive credit.

Studio repo name: studio4- (from your sticker)

People on your team:

Last name 6-digit ID

TA: Password: