atomic. In addition, you should specify appropriate
store, and read-modify-write operations. For full credit, you should specify the minimum orders necessary for correctness. (I’m pretty sure that I have the right specifications in the book, but they were all figured out on paper, and haven’t been tested “in the field,” so it’s at least possible you’ll find a bug; if so, please let me know immediately!)
Students in CSC 258 are required to collect and analyze results on an x86
Students in CSC 458 are additionally required to collect and
on an IBM Power machine (CSC 258 students may do so for extra
As with the x86, there are identical machines on the teaching and
Students in CSC 458 should develop and debug their code on an x86 machine
first. Because of its more relaxed memory model, the IBM machine
may expose bugs that are hidden on the x86.
As in the previous assignment, your microbenchmark
should take as input two optional parameters
t and i, specified as command-line arguments.
For each program phase (each lock algorithm listed above),
you should output the time required for each
of t threads, running concurrently, to increment a shared counter
i times (a total of t * i increments).
Please use the same program name and
Makefile that you used
in that assignment.
Try your program with varying numbers of threads, both greater and fewer
than the number of processors in the machine.
Powers of two and the values halfway in-between (1, 2, 3, 4, 6, 8, 12, 16,
24, 32, 48, 64, 96, 128) are often good choices.
See the previous assignment for further
Report final counter values and throughput (measured in increments per millisecond) for each phase. Try any other tests that occur to you. Explain your results (in writing) in a README.pdf file (do not submit Word, OpenOffice, dvi, or other formats). We will be grading the assignment on a mix of completeness and correctness, programming style, and quality of write-up, with an emphasis on the latter. Note that explaining your results entails more than a detailed report of what happened: it entails a convincing discussion of why it happened.
To turn in your code, follow the turnin directions. If you have questions, post to the discussion board.
To get accurate timings you’ll need to run when no one else is
running. I suggest that you do code development on one of the
standard cycle servers (or your own laptop, if you prefer).
When you’re happy with your code, run x86 timing experiments on
Students in other courses will be using
You can develop on that machine if you like, but it may not be reliable
for timing experiments.
Again, please perform your timing experiments
in person in the Systems lab [CSB 727] or the
Hylan Lab [for undergrads and MS students] so you can coordinate with
other students and avoid messing up each others’ results.
Before you log out, be sure to run
(and, if necessary,
to make sure you don’t leave any run-away processes behind.
And be sure to get your code working early:
if you leave this assignment to the last minute, you’re
unlikely to be able to get solo time on the machine, or to have time to
adequately explain your results.