Adjust wording of "static priority" comment.

[pintos-anon] / doc / threads.texi

diff --git a/doc/threads.texi b/doc/threads.texi
index 74f51bcba15eef66817ced9ae41b35dfeaad0e60..1e379710c65c3d38f06a6e168b3fb6a6d5b80814 100644 (file)
--- a/doc/threads.texi
+++ b/doc/threads.texi
@@ -447,9 +447,9 @@ Implement priority scheduling in Pintos.  Priority scheduling is a key
 building block for real-time systems.  Implement functions
 @func{thread_set_priority} to set the priority of the running thread
 and @func{thread_get_priority} to get the running thread's priority.
-(A thread can examine and modify only its own priority.)  There are
-already prototypes for these functions in @file{threads/thread.h},
-which you should not change.
+(This API only allows a thread to examine and modify its own
+priority.)  There are already prototypes for these functions in
+@file{threads/thread.h}, which you should not change.
 
 Thread priority ranges from @code{PRI_MIN} (0) to @code{PRI_MAX} (59).
 The initial thread priority is passed as an argument to
@@ -490,6 +490,10 @@ for a lock held by a lower-priority thread.  You do not need to
 implement this fix for semaphores, condition variables or joins.
 However, you do need to implement priority scheduling in all cases.
 
+You may assume a static priority for priority donation, that is, it is
+not necessary to ``re-donate'' a thread's priority if it changes
+(although you are free to do so).
+
 @node Problem 1-4 Advanced Scheduler
 @section Problem 1-4: Advanced Scheduler
 
@@ -503,10 +507,6 @@ relative to the original Pintos scheduling algorithm (round robin) for
 at least one workload of your own design (i.e.@: in addition to the
 provided test).
 
-You may assume a static priority for this problem. It is not necessary
-to ``re-donate'' a thread's priority if it changes (although you are
-free to do so).
-
 You must write your code so that we can turn the MLFQS on and off at
 compile time.  By default, it must be off, but we must be able to turn
 it on by inserting the line @code{#define MLFQS 1} in
@@ -646,6 +646,34 @@ integers? Do I need to check for that?}
 Don't worry about the possibility of timer values overflowing.  Timer
 values are expressed as signed 63-bit numbers, which at 100 ticks per
 second should be good for almost 2,924,712,087 years.
+
+@item
+@b{The test program mostly works but reports a few out-of-order
+wake ups.  I think it's a problem in the test program.  What gives?}
+
+This test is inherently full of race conditions.  On a real system it
+wouldn't work perfectly all the time either.  However, you can help it
+work more reliably:
+
+@itemize @bullet
+@item
+Make time slices longer by increasing @code{TIME_SLICE} in
+@file{timer.c} to a large value, such as 100.
+
+@item
+Make the timer tick more slowly by decreasing @code{TIMER_FREQ} in
+@file{timer.h} to its minimum value of 19.
+
+@item
+Increase the serial output speed to the maximum of 115,200 bps by
+modifying the call to @func{set_serial} in @func{serial_init_poll} in
+@file{devices/serial.c}.
+@end itemize
+
+The former two changes are only desirable for testing problem 1-1.  You
+should revert them before working on other parts of the project or turn
+in the project.  The latter is harmless, so you can retain it or revert
+it at your option.
 @end enumerate
 
 @node Problem 1-2 Join FAQ