Wording clarifications.

[pintos-anon] / doc / threads.texi

diff --git a/doc/threads.texi b/doc/threads.texi
index 58cf31609fd1d956e2c70285db3d4bfa1c1e8adf..28b87fadaca14d2e2a5f61c76cf9c1b6883c40ff 100644 (file)
--- a/doc/threads.texi
+++ b/doc/threads.texi
@@ -461,10 +461,9 @@ a lock that @var{M} holds and @var{M} is waiting on a lock that @var{L}
 holds, then both @var{M} and @var{L} should be boosted to @var{H}'s
 priority.
 
-You need not implement priority donation when a thread is waiting
-for a lock held by a lower-priority thread.  You need not
-implement priority donation for semaphores or condition variables,
-but you are welcome to do so.  You do need to implement
+You must implement priority donation for locks.  You need not
+implement priority donation for semaphores or condition variables
+(but you are welcome to do so).  You do need to implement
 priority scheduling in all cases.
 
 Finally, implement the following functions that allow a thread to
@@ -481,6 +480,9 @@ Returns the current thread's priority.  In the presence of priority
 donation, returns the higher (donated) priority.
 @end deftypefun
 
+You need not provide any interface to allow a thread to directly modify
+other threads' priorities.
+
 The priority scheduler is not used in any later project.
 
 @node Advanced Scheduler
@@ -497,7 +499,7 @@ have the priority scheduler working, except possibly for priority
 donation, before you start work on the advanced scheduler.
 
 You must write your code so that we can choose a scheduling algorithm
-policy at Pintos startup time.  By default, the round-robin scheduler
+policy at Pintos startup time.  By default, the priority scheduler
 must be active, but we must be able to choose the 4.4@acronym{BSD}
 scheduler
 with the @option{-mlfqs} kernel option.  Passing this
@@ -510,6 +512,8 @@ directly control their own priorities.  The @var{priority} argument to
 @func{thread_set_priority}, and @func{thread_get_priority} should return
 the thread's current priority as set by the scheduler.
 
+The 4.4@acronym{BSD} scheduler does not implement priority donation.
+
 The advanced scheduler is not used in any later project.
 
 @node Project 1 FAQ
@@ -627,7 +631,7 @@ list.
 Yes.  As long as there is a single highest-priority thread, it continues
 running until it blocks or finishes, even if it calls
 @func{thread_yield}.
-If there are multiple threads have the same highest priority,
+If multiple threads have the same highest priority,
 @func{thread_yield} should switch among them in ``round robin'' order.
 
 @item What happens to the priority of a donating thread?
@@ -653,6 +657,12 @@ processor.  It is not acceptable to wait for the next timer interrupt.
 The highest priority thread should run as soon as it is runnable,
 preempting whatever thread is currently running.
 
+@item How does @func{thread_set_priority} affect a thread receiving donations?
+
+It should do something sensible, but no particular behavior is
+required.  None of the test cases call @func{thread_set_priority} from a
+thread while it is receiving a priority donation.
+
 @item Calling @func{printf} in @func{sema_up} or @func{sema_down} reboots!
 
 @anchor{printf Reboots}