write, explain how we can use them, and show some sample output from a
run.
-Specifically, here are some pointers for writing @file{TESTCASE} files
-which will make them more succinct and us more likely to understand the
-tests you write:
+Here are some pointers for writing @file{TESTCASE} files:
@itemize @bullet
@item
@item
Clearly state in your @file{TESTCASE} file what each test is supposed
to test. You should be testing not only the common case, but testing
-corner cases. Specify what criteria or issue is being tested. For
-example, in testing @func{thread_join} you would have specified that
-you test @func{thread_join} when it is called multiple times on the
-same child thread.
+corner cases. Specify what criteria or issue is being tested.
@item
-Make your tests as succinct as possible. Most students in the past
-have done a great job with the testing of @func{thread_join},
-creating very succinct short tests. We like that.
+Make your tests as succinct as possible.
@item
Your test cases should be placed in a subdirectory called
the following to test your virtual memory implementation's ability to
expand the stack:
@example
-int main (void) {
+int main (void) @{
int array[4096];
array[123] = 234;
return 0;
-}
+@}
@end example
@noindent The compiler is quite likely to notice that the value that you
write to the array is never used again and thereby decide not to write
improvements that your code makes to the performance of the system.
You should be able to show us ``before'' and ``after'' performance
data, and explain how the data shows the improvement. For example,
-for Problem 1-4, you should show us in the @file{TESTCASE} printouts
+for Problem 1-3, you should show us in the @file{TESTCASE} printouts
from a workload for the non-Solaris scheduler and the Solaris
scheduler and explain why the Solaris scheduler is better.