Objective

For this project, you will do an empirical study of the issue we discussed in class: having multiple threads update a shared counter. You will learn to write code that starts and joins threads, and performs synchronization, yields, and sleeps. Note that this study will not demonstrate the effectiveness of multiple threads. In fact, we'll be doing one of the worst possible things you could do with multiple threads: having them all contend to update one shared resource.

Description

This project is somewhat freeform, in that you do not have to implement a particular API. Rather, you simply need to implement whatever code you need to perform the experiements described here.

You should start out your project by checking out h5-MeasuringThreads from your CVS repository.

You'll want to vary several options for your study:

• The number of threads (try it with 1, 5, and 25 threads)
• whether or not synchronization is used
• what, if anything, occurs between the read and write of the shared counter. Possibilities include:
  • nothing other that the addition
  • a call to Thread.yield()
  • a call to Thread.sleep(1). For a call to sleep, you'll need to put in a try/catch block to handle an InterruptedException. Don't worry about dealing with the exception, no interrupts will occur in our study.

To do this, your code will need to:

• Set the shared counter to 0.
• Note the start time (using System.millisecs() or System.nanoTime()).
• Create the appropriate number of threads
• Start the threads
• Join with all of the threads (waiting for them all to complete)
• Note the finish time
• Report the number of missing increments and the number of milliseconds per increment.

Each thread contain a loop that executes (# total iterations / # threads) times. Inside the body of the loop (optionally while holding a lock), read the shared counted, do one of the three types of pauses mentioned above, and then write back 1 plus the value previously read for the shared counter.

There isn't any good way to optionally perform synchronization. You can just have two different Runnable objects, one of which uses synchronization and the other one which doesn't, or you can just comment the synchronization in and out.

You should measure 2 things for each run:

• The number of elapsed milliseconds for the run.
• The number of increments per millisecond.

In our experiments, we found that using a total 100,000 increments, distributed equally among all the threads, was useful but you might find using a different number of total increments more useful, depending on the computer you use to evaluate it.

Note that you may wish to try running the experiment multiple times within one invocation of them JVM. Because of the way the JVM initially interprets code, and then compiles optimized versions of it to execute, you may find that if you conduct a test multiple times with the same parameters within the same JVM, you will consistently see certain differences between a first run and a later run. You will also see random variations, just based on things such as when garbage collection runs.

Please submit two tables, with the columns being number of threads, and the rows being the 6 combinations of synchronized or nonsynchronized and no-pause/yield/sleep. One table should give the number of missing increments, and the other table should give the number of increments per millisecond.

Please note any changes you noticed between first runs and later runs in the JVM, and describe which was used in your tables. Briefly summarize your empirical results. Note how many processors the computer you ran it on has.

Feel free to present your data in ways different that described above, it your presentation contains the same data and you think it makes the data easier to understand.

You can choose to use just one version of your code, in which you, for example, manually change the yield into a sleep, or you can write a more flexible version in which this is controlled by parameters or flags. Either is fine.

Please also include the code you used for testing. If you manually changed it to experiment with different options, please include a version which includes synchronization and uses a yield.

Grading

Your project will be graded as follows:

• 60% Write up of the experimental results
• 30% Valid and reasonable implementation strategy.
• 10% Implementation style

Testing

Notice that there are no public/release/secret tests associated with this project. You do not need to provide any test cases.

Submission

Submit your executable project using the submit project option associated with Eclipse. You can provide your writeup either as a file in that directory, or hand in a printout.

Academic Integrity

Please make sure you read the academic integrity section of the syllabus so you understand what is permissible in our programming projects.  We want to remind you that we check your project against other students' projects and any case of academic dishonesty will be referred to the University's Office of Judicial Program