X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=doc%2Fthreads.texi;h=6b93dbb0badbdd7cab26cb02e6ecee2826248167;hb=35fe5d2c6ea34654bfe8e6e0cc2a5b1bdb937b6c;hp=58cf31609fd1d956e2c70285db3d4bfa1c1e8adf;hpb=615bf3b3d2a8573ed6fb9ddc0055745e163ac999;p=pintos-anon diff --git a/doc/threads.texi b/doc/threads.texi index 58cf316..6b93dbb 100644 --- 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. @@ -461,10 +466,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 +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 @@ -497,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 @@ -510,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 @@ -627,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? @@ -653,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}