|
Boost Users : |
From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-10-13 02:25:55
Peter Dimov wrote:
> This isn't quite true for this specific case. It isn't entirely correct to
> say that absolute waits are a basic primitive, while relative waits are a
> convenience. Both are basic primitives;
I already perceived this, as you can see from another post.
Altough I still think that implementing a "true" relative wait/sleep
is a nontrivial task. This might conceptually not be too problematic
for sleep, but certainly is for wait, since one need to compensate for
spurious wakeups.
> Preemptions aren't an issue specific to relative timeouts since a wait with
> an absolute timeout can as easily be preempted on the way out as a relative
> wait on the way in.
Hmm, sure? I mean "as easily"? I think the probability of being
preempted short after having got a time slice from the scheduler
is smaller than in the average. (Assuming equal thread priorities.)
So one could reason that the way out is more "stable" than the way in.
What do you think?
> There is some rationale for POSIX's decision to go with the absolute timeout
> option in
>
> http://www.opengroup.org/onlinepubs/009695399/xrat/xsh_chap02.html
Thank you for the pointer.
Interesting is the assumption this document draws about the expected
usage of relative times:
"When these functions are given relative timeouts, the timeouts are
typically for error recovery purposes and need not be so precise."
Roland
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net