In message <[EMAIL PROTECTED]>, Nate Williams writes:
>How are issues (1) and (3) above different?
>
>ps. I'm just trying to understand, and am *NOT* trying to start a
>flame-war. :) :) :)
If the starvation happens to hardclock() or rather tc_windup() the effect
will be cummulative and show up in permanent jumps in the output of date
for instance. In stable hardclock() is spl-protected so this would be
_really_ bad news.
If the starvation happens in any of {micro|nano}[up]time() (but not the
"get&" variants!) the it will result in a single spurious reading.
The premise for avoiding locking in the access functions to timecounters
where precisely that we could trust them to not be pre-empted for long
enough for the hardware to roll over, if this is not the case we loose
because the overflow in the hardware counter means that the timecounter
we calculate from is not valid for the delta we get from the hardware.
I'm not sure this answers your question, if not it is not bad will, just
me not understanding the question :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
