[Bug libstdc++/41861] [DR 887][C++0x] <condition_variable> does not use monotonic_clock

[Bug libstdc++/41861] [DR 887][C++0x] <condition_variable> does not use monotonic_clock

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |NEW

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-07-03 16:23:30 UTC ---
887 is NAD, reopening.

This is a QoI issue, but even if monotonic clock support was added to gthreads
(by which I assume people mean providing an API for pthread_condattr_setclock)
we couldn't meet all the QoI suggestions.

The standard says implementations should use a steady clock for xxx_for, but
should use the user-provided clock for xxx_until.  It's not possible to do both
on POSIX, because a condition variable has a single clock, set on construction,
and mutexes always use the system clock.

[Bug libstdc++/41861] [DR 887][C++0x] <condition_variable> does not use monotonic_clock

[mac at mcrowe dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861

--- Comment #9 from Mike Crowe <mac at mcrowe dot com> ---
It seems that there's been lots of talk about this but no firm solution. Here's
some interesting links:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2999.html

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4486.html (search
for "887")

https://www.redhat.com/archives/posix-c++-wg/2009-July/msg00002.html
(search for "887")

https://github.com/cplusplus/LWG/blob/master/xml/issue0887.xml

To me they seem to boil down to three points of view:

1. The current implementation of converting all other clocks to the
system_clock is acceptable behaviour. Unfortunately this is racey when the
system clock is changed and could cause the caller to wait for far longer than
requested.

2. Implementers should add an extra constructor parameter (or perhaps template
parameter) to condition_variable to allow the master clock for the
condition_variable to be configured. All clocks would then be converted to this
clock. This would allow the client code to express its intent but it seems ugly
to require platform-specific code to make the standard behaviour actually work.

3. condition_variable should support wait_until using at least steady_clock
(CLOCK_MONOTONIC) and system_clock (CLOCK_REALTIME.) Relative wait operations
should use steady_clock. User-defined clocks should probably convert to
steady_clock.

I believe that only option 3 makes any sense but this requires an equivalent to
pthread_cond_timedwait that supports specifying the clock. The glibc
implementation of such a function would be straightforward.

[Bug libstdc++/41861] [DR 887][C++0x] <condition_variable> does not use monotonic_clock

[mac at mcrowe dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861

--- Comment #10 from Mike Crowe <mac at mcrowe dot com> ---
(In reply to Mike Crowe from comment #9)
> 3. condition_variable should support wait_until using at least steady_clock
> (CLOCK_MONOTONIC) and system_clock (CLOCK_REALTIME.) Relative wait
> operations should use steady_clock. User-defined clocks should probably
> convert to steady_clock.
> 
> I believe that only option 3 makes any sense but this requires an equivalent
> to pthread_cond_timedwait that supports specifying the clock. The glibc
> implementation of such a function would be straightforward.

I've proposed a patch that implements this option at:

 https://gcc.gnu.org/ml/libstdc++/2015-07/msg00024.html

and the required glibc change at:

 https://sourceware.org/ml/libc-alpha/2015-07/msg00193.html

[Bug libstdc++/41861] [DR 887][C++0x] <condition_variable> does not use monotonic_clock

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Aaron, your reply got added to Bug 887 for some reason.

Re-posting Aaron's comment here:

>Thanks. I had already patched our gcc so that gthreads cond always gets
>initialized with CLOCK_MONOTONIC, then I switched __clock_t in
>condition_variable to steady_clock. It was a very simple change and works
>well but not nearly as portable as yours.
>
>I also disabled all timed waits on mutex (gcc already has ifdef for that)
>in order to avoid problems there. In my opinion, people shouldn't be using
>timed waits on mutexes anyway, since they are not cooperatively
>interruptible. If we did need them for some reason, I would reimplement
>timed mutex in terms of condition_variable and a regular mutex.
>
>It seems strange that this is no big deal to lots of people.

[Bug libstdc++/41861] [DR 887][C++0x] <condition_variable> does not use monotonic_clock

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED
            Summary|[C++0x] <condition_variable>|[DR 887][C++0x]
                   |does not use monotonic_clock|<condition_variable> does
                   |                            |not use monotonic_clock


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861