Roland Schwarz wrote:
Please don't forget: the threading library supply you with the essential primitives. You might always need to create other convenience functions if needed. You cannot get the behaviour from the example when only a relative sleep is available.
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; sometimes an absolute timeout better fits the problem, and sometimes the opposite is true. In addition, sometimes the underlying implementation emulates absolute timeouts on top of relative timeouts, sometimes the opposite is true. You can emulate the behavior from the example with relative timeouts as long as you have access to the current time of the clock by which the absolute time is measured. 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. It's clear that our current xtime mechanism is only a stop-gap measure; unfortunately, nobody has proposed a well thought-out alternative (so far). The C++ committee will have to address the issue one way or the other, though, and there isn't much time left. 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 A previous section also addresses the monotonic clock.