University of Washington, Bothell
CSS AP442: Advanced Programming Methodology I
Autumn 1998
Homework Assignment 2: Concurrency and Synchronization
Assigned: 3 November 1998
Due: 15 November 1998 by midnight

Purpose

This assignment will give you experience using concurrent processes to perform a simple simulation. In this simulation, two opponents on mountain bikes with different characteristics are competing in a race. You will place each competitor in a separate thread, and will need to synchronize their activities.

The Race

The race course is 700 meters long, and winds up and down a mountain, so occasionally one or the other cyclist will lose ground. You needn't worry about the course topography, however, as you will use random number generation to determine how each is progressing. Instead, divide the race into 70 10-meter segments, with the competitors starting in segment 0 and the finish line being segment 69. For simplicity's sake, just think of the course as being a linear arrangement of segments.

Each second, the competitors' threads will be notified to recompute their location in the race according to the following rules:

Competitor	Action	Probability	Result
1	Sprint	0.5	+3 segments
	Grind	0.3	+1 segment
	Slip	0.2	-6 segments
2	Sprint	0.2	+9 segments
	Glide	0.3	+1 segment
	Rest	0.2	0 segments
	Slip	0.2	-2 segments
	Fall	0.1	-12 segments

You may decide to use different classes for each competitor, or use one class and create two objects whose ``move probability tables'' are loaded at construction time (or some similar idea). In either event, each player's object should contain a thread which tracks and updates its race position. At no time may a player's position be less than zero or greater than 69; if a player slips or falls and would move back past zero, just move that player to segment zero, and the first player to reach segment 69 wins. You may compute the probabilities by generating integers in the range of $1 \leq i \leq 10$.

Begin the race by printing: They're off!!!. Thereafter, each player gets one move per tick of the race clock. For each tick, after both bicyclists have moved, you should determine the location of each and print two lines that have a 1 or 2 in the column that corresponds to his/her current segment, and are blank elsewhere. You should then test to see if either contestant has won, and print out a message like Cyclist 1 wins!. Note that there can be ties. If neither cyclist has won yet, their threads should be notified to compute a new position.

Statement of Work

Write a program which simulates a two-contestant mountain bike race, with each cyclist placed in separate threads. At the start of the race, call each thread's start() method. Use wait(), notify(), and notifyAll() to synchronize the contestants' activities.

Extra Credit

Design and implement the program so that an arbitrary number of cyclists can compete. Your program should take the number of competitors as its sole command line argument. The race status output should display one line per competitor. The probability tables for the additional cyclists should be generated randomly, such that the weighted sum for each (sum of probabilities times corresponding moves) is between 0.2 and 0.8 (average number of segments per time step).

Things to Consider

• Your program must be called Dirt; i.e., main() should be in a class defined in Dirt.java.
• It is important to keep in mind the functionality of each class. The contestant objects' responsibilities are to: know their current position, recompute their position within their contained thread, make sure that their thread is properly synchronized with the ongoing race, and be able to return their current position when an inquiry is received. In principle, we could replace the simple display here with a graphical one. Therefore, the cyclist class(es) cannot contain any user interface elements: all UI must be performed by the rest of your program.
• It is essential that you produce a thorough specification for each class and the complete program before you commence with the design.
• Your grade will be based partly on design documentation. Please submit:
  • a complete specification,
  • UML class hierarchy diagram(s),
  • OMT class diagrams,
  • UML instance diagrams,
  • state diagrams,
  • and JSP diagrams for non-trivial algorithms (if any).
• Document your source code. Each function should have a header in comments which describes its purpose, arguments, return values, pre- and post-conditions, and a summary of the algorithm.
• Please adhere to reasonable coding style (i.e., no gotos, consistent and useful indentation, etc).
• It is your responsibility to verify that your program will compile using the javac compiler that comes with the JDK, and run using java (you should be writing an application, not an applet). This will allow us to automate compilation of everyone's code, speeding feedback to you.

Submitting Your Work

You will be submitting your source code separately from your documentation. Please email your source code to cssap442@u.washington.edu. You may submit an entire directory structure as a zip or tar file attachment, in which case your subject line should read, for example: ID#.zip, where ``ID#'' is replaced by your student ID number. Please ensure that long file names are preserved.

Alternatively, each file can be sent in a separate email message as an attachment or in the body, with the subject line: ID# subdirectory/filename.java, showing the subdirectory name for any package files. Please ensure that no lines get wrapped or truncated!

Any email sent after the due date/time will be counted as a late submission. You will receive one automated response, which you should save as a receipt of submission. Please send your code only once; multiple submissions will slow our turn-around time to everyone.

Your program must be called Dirt; i.e., main() should be in a class defined in Dirt.java. Please submit your documentation as hardcopy in the next class meeting after the due date. Include information about the status of your assignment, if it is not completely working.

About this document ...

This document was generated using the LaTeX2HTML translator Version 98.1p1 release (March 2nd, 1998)

Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.

The command line arguments were:
latex2html -split 0 assn2.

The translation was initiated by Dr. Michael Stiber on 1998-11-03