X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;ds=sidebyside;f=doc%2F44bsd.texi;h=3f1791880e82efa6b27677ca2e882e4bf3725058;hb=c52ac89c100e80b6af53a0d047b4432a5c30033e;hp=84ddf7f1e0df3036e074aec6c4f832cbf3e98dac;hpb=4ebf33908a571a7cde93fe618902b044e3633cdf;p=pintos-anon

diff --git a/doc/44bsd.texi b/doc/44bsd.texi
index 84ddf7f..3f17918 100644
--- a/doc/44bsd.texi
+++ b/doc/44bsd.texi
@@ -52,6 +52,12 @@ time, the scheduler chooses a thread from the highest-priority non-empty
 queue.  If the highest-priority queue contains multiple threads, then
 they run in ``round robin'' order.
 
+Multiple facets of the scheduler require data to be updated after a
+certain number of timer ticks.  In every case, these updates should
+occur before any ordinary kernel thread has a chance to run, so that
+there is no chance that a kernel thread could see a newly increased
+@func{timer_ticks} value but old scheduler data values.
+
 @menu
 * Thread Niceness::             
 * Calculating Priority::        
@@ -64,19 +70,20 @@ they run in ``round robin'' order.
 @section Niceness
 
 Thread priority is dynamically determined by the scheduler using a
-formula given below.  However, each thread also has a relatively static
-@dfn{nice} value between -20 and 20 that determines how ``nice'' the
-thread should be to other threads.  A @var{nice} of zero does not affect
-thread priority.  A positive @var{nice} increases the numeric priority
-of a thread, decreasing its effective priority, and causes it to give up
-some CPU time it would otherwise receive.  On the other hand, a negative
-@var{nice} tends to take away CPU time from other threads.
+formula given below.  However, each thread also has an integer
+@dfn{nice} value that determines how ``nice'' the thread should be to
+other threads.  A @var{nice} of zero does not affect thread priority.  A
+positive @var{nice}, to the maximum of 20, increases the numeric
+priority of a thread, decreasing its effective priority, and causes it
+to give up some CPU time it would otherwise receive.  On the other hand,
+a negative @var{nice}, to the minimum of -20, tends to take away CPU
+time from other threads.
 
 The initial thread starts with a @var{nice} value of zero.  Other
 threads start with a @var{nice} value inherited from their parent
-thread.  You
-must implement these functions, for which we have provided skeleton
-definitions in @file{threads/thread.c}.
+thread.  You must implement the functions described below, which are for
+use by test programs.  We have provided skeleton definitions for them in
+@file{threads/thread.c}.  by test programs
 
 @deftypefun int thread_get_nice (void)
 Returns the current thread's @var{nice} value.
@@ -172,14 +179,13 @@ current value of @var{recent_cpu} decays to a weight of .1 in
 received ``recently,'' with the rate of decay inversely proportional to
 the number of threads competing for the CPU.
 
-Because of assumptions made by some of the tests, @var{recent_cpu} must
-be updated exactly when the system tick counter reaches a multiple of a
-second, that is, when @code{timer_ticks () % TIMER_FREQ == 0}, and not
-at any other time.
+Assumptions made by some of the tests require that updates to
+@var{recent_cpu} be made exactly when the system tick counter reaches a
+multiple of a second, that is, when @code{timer_ticks () % TIMER_FREQ ==
+0}, and not at any other time.
 
-Take note that @var{recent_cpu} can be a negative quantity for a thread
-with a negative @var{nice} value.  Negative values of @var{recent_cpu}
-are not changed to 0.
+The value of @var{recent_cpu} can be negative for a thread with a
+negative @var{nice} value.  Do not clamp negative @var{recent_cpu} to 0.
 
 You must implement @func{thread_get_recent_cpu}, for which there is a
 skeleton in @file{threads/thread.c}.
@@ -313,7 +319,7 @@ q}:
 @tab @code{n * f}
 
 @item Convert @code{x} to integer (rounding down):
-@tab @code{x * f}
+@tab @code{x / f}
 
 @item Convert @code{x} to integer (rounding to nearest):
 @tab @code{(x + f / 2) / f}