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