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