The files are
The first driver is just the same as that used in assignment 5. The second driver tests thread priority. The third driver tests dynamic thread creation. You'll have to write your own driver to test locking. Rough C code for testing the lock code is available.Sample output from running my sample solution (not provided) with the above drivers is now available. Output from an implementation that schedules the threads slightly differently, with the same set of drivers, is also available.
You may also want to look at the sample solution for assignment 5 as another starting point.
We tested with the following drivers:
The grade distribution is
The grade distribution is
124 students handed in assignment 6. assignment 6 as a whole: mean 39.602 stdev 35.3735 w/o late adjustment: mean 40.25 stdev 35.3363 Excluding all-zero scores: assignment 6 as a whole: mean 63.7747 stdev 21.7589 w/o late adjustment: mean 64.8182 stdev 20.4538 Per-problem statistics: Num 1: mean 10.201613 stdev 9.783940 Num 2: mean 3.991935 stdev 6.155899 Num 3: mean 6.000000 stdev 8.041224 Num 4: mean 8.790323 stdev 8.361079 Num 5: mean 11.266129 stdev 9.672132 Per-problem statistics, omitting zero grades: Num 1: mean 18.880597 stdev 3.646803 Num 2: mean 8.684211 stdev 6.456760 Num 3: mean 14.307692 stdev 5.943770 Num 4: mean 15.138889 stdev 4.928110 Num 5: mean 19.136986 stdev 2.877951
One thing we looked for was the ability for the threads package to be used by a long-running multithreaded program. If your dynamic thread creation just extended the thread table, this means that after 256 threads are created/initialized and then exited, the thread table fills up and the thread package will crash. It is much better to scan the table for an unused slot, where some previous thread had run and completed.
bsy+www@cs.ucsd.edu, last updated