From e51a2c998091aa0985c218a197b3c655fa174376 Mon Sep 17 00:00:00 2001 From: Ben Pfaff Date: Tue, 20 Dec 2005 18:03:02 +0000 Subject: [PATCH] Wording clarifications. --- doc/44bsd.texi | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/doc/44bsd.texi b/doc/44bsd.texi index 3bbce0d..3f17918 100644 --- a/doc/44bsd.texi +++ b/doc/44bsd.texi @@ -179,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}. -- 2.30.2