CSE 132 (Spring 2010)
Midterm Exam

Name: ________________________  Last 3 ID digits: ____________________
  1. Concurrency
    Do this part on your own, not in studio!
    In your repository you will find a midterm package with an implementation of MyColor (from Quiz 1) and RWLock (from Studio 5).

    There is a JUnit test there too, which when you run, will throw errors because the MyColor class is not thread-safe.

    Using readers/writer locks (an RWLock is already instantiated in MyColor), protect the code in MyColor so that it is threadsafe but allows the greatest concurrency possible while being thread-safe.

    • Do not use synchronized! Use the RWLock instance, and use it properly and well.
    • Review the RWLock class, and remember that you can get work done with such locks in two ways:
      • By passing a Runnable to the appropriate method (for example, acquireReadWrite(Runnable r))
      • By bracketing the code you want protected with calls to acquire and release the lock (for example, acquireReadOnly().....release())
    • Your code when properly protected should pass the unit test with no errors, and you will receive at least 70% of the credit for this problem if you pass the unit test without violating the notes in the files you are given.
    • You will receive credit beyond 70% for this problem only if you show wise use of the RWLock, allowing for the most concurrency while avoiding unwanted races.

      Ask me (RKC) if you have any questions.

  2. Model/View/Controller
    This part of the exam will be started in studio and finished on your own. Get as far as you can in studio.
    You will find a weasley package in your personal repo. In studio, you and your studio partners will each open your own repository, but you can collaborate on the design during the studio session. On your own, you will then complete the code in the weasley package and turn it in for grading with your midterm.

    Below is a user story for the Weasley clock. Read it carefully, and consult the Main class in the weasley package to see the details of the story.

    Keep in mind the separation of model from view, and the use of PropertyChangeSupport to couple the two. Place your classes in weasley.model or weasley.view as appropriate.

    A Weasley object keeps track of people and their current location. A Person is constructed based on the person's name. Likewise, a Location is constructed based on the location's name. The methods that can be called on a Weasley are used in Main and are self-explanatory, but ask questions if anything is unclear.

    A Bouncer should be notified when somebody moves in a particular Weasley to a particular Location. It should simply print out a message when this sort of thing happens.

    A Stalker should react when a particular Person changes location in a particular Weasley. Again, just print a message when something like this happens.

    The Logger logs all changes to any person's location by printing a suitable message.



Last modified 09:00:10 CDT 03 June 2010 by Ron K. Cytron