Re: nanosleep() uses CLOCK_MONOTONIC, should be CLOCK_REALTIME?

["Michael Kerrisk" <mtk.manpages@googlemail.com>]

Roman,

On Mon, Jun 23, 2008 at 2:43 PM, Roman Zippel <zippel@linux-m68k.org> wrote:
> Hi,
>
> On Mon, 23 Jun 2008, Michael Kerrisk wrote:
>
>> >> Is there a reason to use CLOCK_MONOTONIC, instead of CLOCK_REALTIME?  Is it
>> >> intentional?  If yes, then I should document this in the man-pages.  If not,
>> >> then it should be fixed.
>> >
>> > CLOCK_MONOTONIC works fine even if ntpd steps the clock forward or
>> > backward, CLOCK_REALTIME not. So the man page should be fixed.
>>
>> Thanks for your reply, but I'm not quite convinced yet.  The things
>> is: the Solaris man page also says "CLOCK_REALTIME".  (Of course that
>> man page may just be parroting the standard.)  Could there not be some
>> reasonable semantics for a nanosleep() that was based on
>> CLOCK_REALTIME?
>
> CLOCK_MONOTONIC is optional, that's probably the reason it's not mentioned
> there.

This seems a little unlikely.  POSIX specifies clock_nanosleep() (see
my other reply) specifically to allow for clocks other than
CLOCK_REALTIME.

> 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).

I'll add some text (not quite sure what yet) in the nanosleep() man
page on this point.

Thanks Roman, Bart.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html