Tuesday, March 27, at 11:00 am.
IMPORTANT: There was a bug that could cause the progream to deadlock under certain race conditions. There was another bug that could (very rarely) cause the program to hang on shutdown.
Please fetch new copies of Request.java, Warehouse.java, and P3.java from ~cs537-1/public/html/source/p3. See the News section of the home page for more details.
Congratulations! Your grain trading program from project 2 was so successful, your company was acquired by The Chicago Board of Trade for $500 million! However, as part of the “due diligence” associated with the acquisition, an analyst at CBOT questioned whether your algorithm is as efficient as it should be. CBOT had your program rewritten, replacing the multiple Traders with a single, centralized Warehouse process which can look at all pending orders and allocate resources to them “optimally”. CBOT tried four different algorithms, but cannot decide which is best, so they have assigned you and your partner task of analyzing them. They will not sign the contract until you provide a thorough and convincing analysis.
CBOT wants a written report from you by Tuesday, March 27.
You can find the trading program in ~cs537-1/public/html/source/p3. Copy all the files to a new directory, compile them by typing
javac -Xlint:all *.java
and run the program by typing something like
java P3 1 5 100
Take a look at the source files. See also the online documentation. You will note many similarities project 2, but there are also some important differences. Instead of one Trader for each type of grain, there is now one centralized Warehouse that accepts get orders from all brewers and controls how they are processed. The Warehouse now has its own thread. Whenever a new order is placed by a Brewer or grain is delivered by the Supplier, notify() is called to wake up the Warehouse thread. It allocates resources according to one of four algorithms as specified to the first command-line argument (1 in the example above). You will probably need to make small changes to the code for your experiments.
The details of the program are controlled by several parameters initialized in the constructors for Brewer and Supplier. You will need to experiment with changes to these parameters. You may also need to add code to gather other statistics on the performance of the three algorithms.
The behavior of a Brewer is controlled by the parameters meanSleepTime and maxRequest. The meanSleepTime is the average time (in milliseconds) that the brewer delays between making purchases. The actual time is an exponentially distributed random number with mean meanSleepTime (in the jargon of statistics, this is called a Poisson arrival process). The Order maxRequest controls the amount of each grain purchased by the brewer. The actual amount of grain g requested is a random number uniformly distributed over the interval [0,maxRequest.get(g)], so that the mean purchase is maxRequest.get(g)/2. As you can see from the code, not all brewers need to have the same behavior.
The behavior of the Supplier is controlled by the parameters meanSleepTime and maxSupply. Like brewers, the supplier repeatedly sleeps an exponentially distributed random time and then supplies a random amount of each grain to the trader. The code as distributed attempts to balance the rates of production and consumption of resources. That is, the supplier tries to generate grains at roughly the same rate (on the average) as brewers consume them. (How well does it do?) After the number if iterations specified by the third command-line parameter, the supplier returns and the main method in P3 shuts down the system by interrupting all the Brewer threads and the Warehouse thread, and then prints various statistics.
All random number are generated from the single random-number generator P3.rand. As in project 2, you can specify -r on the command line to minimize to decrease the amount of randomness. If you specify this option, the generator will always be initialized with the same “seed.” However, there is a certain amount of randomness anyhow, so results will not necessarily be the same on every run, even with -r. You my wish to try experiment with -r to see how much the results you see are caused by random fluctuations and how much they are caused by the algorithm and the parameters.
First, look at the methods Warehouse.algorithm1(), Warehouse.algorithm2(), Warehouse.algorithm3(), and Warehouse.algorithm4(). Unfortunately, the CBOT programmers failed to include any comments. What is each algorithm trying to accomplish? Are they analogous to any of the scheduling algorithms discussed in class? What sort of behavior would you expect from each of these algorithms? Should one be “better” than all the others? Perhaps one or another is best depending on the goals (response time, total amount traded, fairness, etc.). Perhaps one or another algorithm is better depending on the characteristics of the “offered load” (parameters of the Brewers and Supplier).
Next, design and some experiments to test your hypotheses. Carefully analyze the results of your experiments. After an initial analysis, you may find that you need to run additional experiments to gather more information.
You should approach this portion of the assignment as you would approach a laboratory assignment in a physics course. Use the scientific method. You should form some hypotheses before you start experimenting and use the experiments to confirm or reject these hypotheses based on observed results. Give careful thought to the correct choice of parameters for the programs. Try a few trial runs with various parameters, print out the results, and go home and think about the results. These preliminary results should help you decide on better parameters for a second round of trials. Remember: It's not the quantity but the quality of data that dictates the quality of the experiments.
If the program is not printing out all the statistics you would like to see, feel free to modify it to produce better output. You may find additional statistics-reporting code can help explain some of the behavior you observe.
You are to prepare a report describing the results of your experiments. Again, approach this report as you would approach a physics laboratory experiment report. You should carefully describe what experiments you did and what the results showed you about the different allocation policies. We want to see a correlation between the experiments you run and the conclusions you draw. You must supply quantitative data to support your conclusions. The report should be not more than three typewritten pages, not including tables, graphs, etc.
Put a copy of your code (.java files only) in the appropriate subdirectory of ~cs537-1/handin. If you have changed partners, let us know as soon as possible. Include all .java files needed to build the program (even the parts we wrote and you didn't change). Do not include .class files. In each .java file, include a comment of the form
// Partner: login1 login2where login1 and login2 are the login names of the partners.
The report itself will be hard copy only (do not try to hand in MS Word
documents or whatever). Bring your report to class on the day the project is
due.
Copyright © 2007 by Marvin Solomon. All rights reserved.