[an error occurred while processing this directive]

Lab 3

CS 5631, Spring 2004
Due Tuesday, March 9 (20 points)

First do the following exercise, then do Lab 3. You need not turn in anything for the exercise, but it is good practice for working with synchronization of Java threads.

Exercise

Complete a Java program that simulates the flow of buffers between multiple producer and consumer threads, with a bounded number of buffers. You will be working with an unsynchronized solution as described in Java Synchronization. You will only have to modify code for two functions, one to take a buffer from a buffer queue, and one to put a buffer back onto a buffer queue. The modifications are also described in Java Synchronization. With a few exceptions, the code that you write will be just like C code.

Setting up

Everything that you will need for this exercise is contained in a file named lab3.jar. You can copy the lab3.jar file from ~gshute/public/cs5631/lab3.jar to wherever you want to do your work for this assignment. After you have obtained a copy give the following command.
    jar xf lab3.jar

If you want to see what files you are getting, you can replace the xf by xvf.

By doing this you have created a subdirectory named lab3. All of the files there are Java code files (.java suffix). The only one that you need to edit is the file BufferQueue.java.

After you have made the code changes described in Java Synchronization, compile BoundedBufferMain.java and execute the BoundedBufferMain class to run the buffer queue simulation. The following command can be given to save the output in a file named "bbm.out".

    java BoundedBufferMain > bbm.out

Further information

The following web pages contain further information that you might want to look at.

Lab 3

Due Tuesday, March 9

Introduction

For Lab 3, implement a simulation of the readers and writers problem. This will involve modifying a class for shared data, and a class for locking readers out while writers are ready to write. When you have completed the modifications, multiple readers and writers will be able to compete for access to shared data, synchronized so that readers do not try to read the data while writers are modifying the data.

There are several possible solutions to this problem. The solution that you will implement gives priority to writers. This ensures that readers are getting the most up-to-date data possible.

An example where this kind of synchronization is useful is flight reservation software. The writers are making reservations, reducing the number of available seats. The readers are checking to see if there are any available seats on a flight.

For this lab, you will be modifying the following files that you obtained earlier.

The places where you need to add code are indicated by // FIXME comments.

Running the simulation

When you have made the code changes, compile your .java files and run the SharedDataMain class. You may want to save the output to a file as you did with the BoundedBufferMain class.

In the output, many of the lines show the value of the shared data before ("reading data" or "writing data") or after ("data read" or "data written") an access. The before and after values should be the same for each reader access. The after value should be one more than the before value for each writer access.

In the log breakout for individual readers, for each read there should be "checks lock" reports until the lock count is 0, followed by a "reading data" report, followed by a "data read" report. In the breakout for writers, for each write there should be an "adds lock" report, followed by a "writing data" report, a "data written" report, and a "removes lock" report.

Writers should be able to add locks at any time, even if a reader is reading. If one writer adds a lock, another should be able to add a lock before the first writer removes its lock. After a writer has added a lock, you may see a "data read" report indicating the completion of of an access that started before the lock was added. Other than that, there should be no read reports until the lock count drops back to 0.

What to turn in

For your lab report, turn in copies of the following.

[an error occurred while processing this directive]