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.
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
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
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
@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
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?
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}