Clarify that adding code where interrupts are already disabled may be

[pintos-anon] / doc / threads.texi

diff --git a/doc/threads.texi b/doc/threads.texi
index f538d8382b2f1554f4457e0241325f3e95ecae62..6b93dbb0badbdd7cab26cb02e6ecee2826248167 100644 (file)
--- a/doc/threads.texi
+++ b/doc/threads.texi
@@ -328,9 +328,14 @@ timer ticks or input events.  Turning off interrupts also increases the
 interrupt handling latency, which can make a machine feel sluggish if
 taken too far.
 
+You may need to add or modify code where interrupts are already
+disabled, such as in @func{sema_up} or @func{sema_down}.  You should
+still try to keep this code as short as you can.
+
 Disabling interrupts can be useful for debugging, if you want to make
 sure that a section of code is not interrupted.  You should remove
-debugging code before turning in your project.
+debugging code before turning in your project.  (Don't just comment it
+out, because that can make the code difficult to read.)
 
 There should be no busy waiting in your submission.  A tight loop that
 calls @func{thread_yield} is one form of busy waiting.
@@ -462,8 +467,8 @@ holds, then both @var{M} and @var{L} should be boosted to @var{H}'s
 priority.
 
 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
+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
@@ -480,6 +485,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
@@ -496,7 +504,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
@@ -509,6 +517,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
@@ -626,7 +636,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?
@@ -652,6 +662,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}