Messages in this thread | | | Date | Wed, 25 Jun 2008 08:13:57 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME? |
| |
On Tue, 24 Jun 2008, Michael Kerrisk wrote: > > If you check the man page for clock_settime, it specifically > > mentions that pending relative timer (including nanosleep) aren't affected > > by the changed time, thus if CLOCK_MONOTONIC and CLOCK_REALTIME advance > > equally, it doesn't matter which you use for relative timer. > > Well, I was going to say that that's just a man page, and man page > authors are fallible ;-). But then I went and had a look at the POSIX > spec for clock_settime(). It includes the following paragraph: > > Setting the value of the CLOCK_REALTIME clock via clock_set- > time() shall have no effect on threads that are blocked waiting > for a relative time service based upon this clock, including > the nanosleep() function; nor on the expiration of relative > timers based upon this clock. Consequently, these time > services shall expire when the requested relative interval > elapses, independently of the new or old value of the clock. > > So that rather flatly contradicts the alternative semantics that I > suggested were possible in my reply to Bart a few minutes ago. > > So in my reading of things now, it looks as though the Linux > implementation is probably fine, since the fact that relative > timers/sleeps are explicitly unaffected by jumps in CLOCK_REALTIME > means that the semantics are effectively the same as if the relative > interval was measured against CLOCK_MONOTONIC (unless the two clocks > counted time at different rates; not sure if that would be possible > in theory, but certainly seems very unlikely in practice).
We use CLOCK_MONOTONIC for the relative timeouts simply to avoid trickery vs. clock_settime(CLOCK_REALTIME). That's an kernel internal implementation detail which does not have any visible effect to the user space interface.
CLOCK_MONOTONIC and CLOCK_REALTIME are using the same timebase internally and therefor we can safely use CLOCK_MONOTONIC for the relative timeouts.
Thanks,
tglx
| |