This Page

Objectives

Due Date

Readers and Writers Problem

Sleeping Barber Problem

Cigarette Smokers Problem

Observer and Status Classes

Update (24-NOV-00) Source for Observer and Status classes

Objectives

• learn to use Java thread-synchronization facilities
• formulate answers to classic and other synchronization and inter-process communication problems

Due Dates

• Second Readers and Writers problem: Wednesday, November 15, 2000
• Modified Sleeping Barber problem: Friday November 24, 2000
• Cigarette-Smokers problem: Friday December 1, 2000

Second Readers and Writers Problem

The solution to the first R&W problem is given in the text. Start by entering the solution as-is and making the following modifications.

• A thread spends its life deciding whether to become a reader or a writer, waiting for reading or writing access, actually reading or writing, and doing other stuff. While reading, writing, or doing other stuff, the thread should sleep to simulate the time spent in that activity. When deciding, the thread should use a random number generator to make a choice. There should be a 2:1 reading:writing ratio. 
• startRead, endRead, startWrite, endWrite should produce a trace which can be used to verify that the problem constraints have not been violated. These traces should be enabled by a common boolean variable so they can be turned off and on.
• each thread should also modify a thread-specific slot in a global state vector that carries the state of all thread. An observer thread periodically reports the contents of the global state vector to the console. For example, the string "RoRwwRo" reports on 7 threads and indicates that threads 0, 2, 5 are reading, 1 and 6 are doing other stuff, and 3 and 4 are waiting to write. Another example is rorWwro, indicating that three processes are waiting to read, one is writing, one is waiting to write, and 2 are doing other stuff. Clearly, a state string with both a capital R and a capital W, or with two capital Ws, indicates a violation of the constraints.

Recall that the first readers and writers problem allows threads to begin reading even if there are some writers waiting. The second readers and writers problem requires that threads wishing to read must wait behind threads that are already waiting to write. This prevents starvation on the part of the writers.

Modified Sleeping Barber Problem

The sleeping barber problem is given on page 223, question 7.10. There are two main modifications which should be made. One is that customers do not turn themselves away if the waiting room is full. The second is that the barber does not actually cut hair himself, but has a minion do it on his behalf. With this change, the sleeping barber resembles a device driver, the minion resembles the device, and the customers resemble I/O-requesting processes. 

Use the same trace facilities as in the readers and writers problem.

The Cigarette-Smoker's problem

This problem is given on page 223, question 7.11. 

Observer and Status classes

These classes are provided in source form for use in your assignments. To use them, 

1. create a single instance of Status and pass it as a construction parameter to classes that need to be traced
2. create a single instance of Observer, pass the instance of Status to its constructor, and call its start() method.
3. call the update method of the Status instance from any other thread, passing a single-character string indicator representing the state of the thread and/or
4. call the udpateCounter method the Status instance passing a string representing the name of the counter.

The run method of the Observer may be modified to print alternative statistics. At present, the Observer prints 

• the state of all threads (getStatus()), 
• the percent of time the system has spent in each state (getFrequencies()), and 
• the values of all counters (getCounters()). 

If no calls to updateCounter have been made, the result of getCounters() will be an empty string. Similarly, if no calls to update have been made, the results of getStatus() and getFrequencies() will be an empty string. 

Each time getFrequencies() is called, it updates an internal table of frequencies based on the current state of each thread before constructing its result from the  internal table of frequencies. The string returned thus adds the current state onto a historical summary of states and provides a breakdown of the system by cumulative state for analysis of throughput.

updateCounter maintains a variable-size table of counters indexed by counter name. This is useful for instrumenting loops, for example spinlocks.