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 2f42e3dc5979b8f8ab33fd79db7af020a285c932..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.
@@ -499,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
@@ -512,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