[Bug libstdc++/41861] New: <condition_variable> does not use monotonic_clock

[Bug libstdc++/41861] New: <condition_variable> does not use monotonic_clock

[atgraham at gmail dot com]

<mutex> looks like this:

171     #ifdef _GLIBCXX_USE_CLOCK_MONOTONIC
172         typedef chrono::monotonic_clock             __clock_t;
173     #else
174         typedef chrono::high_resolution_clock       __clock_t;
175     #endif

...but <condition_variable> only has this:

56          typedef chrono::system_clock        __clock_t;

Shouldn't <condition_variable> be using the monotonic_clock if available, just
like <mutex>?


-- 
           Summary: <condition_variable> does not use monotonic_clock
           Product: gcc
           Version: 4.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: atgraham at gmail dot com


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

[Bug libstdc++/41861] <condition_variable> does not use monotonic_clock

[paolo dot carlini at oracle dot com]

------- Comment #1 from paolo dot carlini at oracle dot com  2009-10-29 00:31 -------
Chris, can you have a look to this issue? Thanks.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cfairles at gcc dot gnu dot
                   |                            |org


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

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

[paolo dot carlini at oracle dot com]

------- Comment #2 from paolo dot carlini at oracle dot com  2009-11-03 11:22 -------
Chris??


-- 


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

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

[cfairles at gcc dot gnu dot org]

------- Comment #3 from cfairles at gcc dot gnu dot org  2009-11-03 13:58 -------
Yes, I'm alive! Starting to get back into the GCC swing of things.

Ok, <condition_variable> and <mutex> and clocks. Its a bit of a tricky
situation, reading current standard draft and other related docs (i.e. posix)
to get myself back up to speed. In my preliminary investigations there seems to
be some issues in assuming what "epoch" means when using gthreads and what we
assume is a "known" clock.

I think condition_variable is more correct than mutex using system_clock as its
"known" clock. Currently mutex doesn't attempt "sync" unknown clocks to a known
clock in its *_until/for functions like condition_variable. This could
potentially be an issue for gthread implementations (and posix implementations
for that matter) where the epoch for system_clock, monotonic and high_res
clocks are all different (let alone user-defined clocks).

So, in condition_variable at least, the assumption is the system_clock epoch
(system_clock::time_point()) == gthread's expected epoch.

Taking the assumption that system_clock::time_point() == gthread's epoch, in
mutex, it erroneously assumes that monotic_clock::time_point() ==
system_clock::time_point() but a quick reading of the POSIX docs shows:

"For [the monotonic] clock, the value returned by clock_gettime() represents
the amount of time (in seconds and nanoseconds) since an unspecified point in
the past (for example, system start-up time, or the Epoch)."
(http://www.opengroup.org/onlinepubs/009695399/functions/clock_gettime.html)

For the POSIX gthread_cond* implementation, the POSIX standard suggests that,
if Clock Selection is available you should set the appropriate condition
attribute (ex. pthread_condattr_setclock if available).

For mutexes (from pthread_mutex_timedlock), 
"If the Timers option is supported, the timeout shall be based on the
CLOCK_REALTIME clock; if the Timers option is not supported, the timeout shall
be based on the system clock as returned by the time() function."

This almost exactly describes system_clock other than the fact that it might
use gettimeofday before using time() (i.e. std::time()), which is still
realative to the POSIX epoch so I think thats ok ... for posix gthreads impl.

Long story short, using monotonic_clock as a "known" clock in *mutex* is almost
certainly incorrect since, in POSIX, its absolute value is meaningless (epoch
is arbitrary). It would be more correct to sync the monotonic_clock to
system_clock like condition_varaible does.

30.2.4p4 says implementations should use a monotonic clock for the *_for
functions that take a relative time. Unfortunately, gthreads (and its POSIX
impl) use absolute time and assumes times are relative to the POSIX epoch.

Let me do a bit more research and poke Howard H. again for some clarification
on this before moving forward.

Chris


-- 


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

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

[cfairles at gcc dot gnu dot org]

------- Comment #4 from cfairles at gcc dot gnu dot org  2009-11-03 15:26 -------
See also:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#887
http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#887


-- 


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

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

[paolo dot carlini at oracle dot com]

------- Comment #5 from paolo dot carlini at oracle dot com  2009-11-03 15:37 -------
Thanks for your feedback Chris. Gosh, that issue, quite a bit of time spent in
Santa Cruz, Detlef arguing was not implementable and Howard disagreeing...


-- 


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

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

[aaron at aarongraham dot com]

------- Comment #6 from aaron at aarongraham dot com  2009-11-10 04:38 -------
So it appears that the problem is gthreads. The monotonic_clock support is
purely superficial in gcc until gthreads supports such a concept. Developers
will need to create their own clock and modify the standard library headers to
use it should they require a reasonable level of reliability in the face of a
possibly-changing system clock.

But I think the Howard/Detlef debate is a separate issue. I believe they have
determined that a condition_variable (and mutex) must continue to use a
specific clock once the object is created, and to sync all given time points to
that clock, and are arguing over whether or not that is implementable. No big
deal. I just don't believe there is any particular requirement that it be the
system_clock (and, if there were, I would think that to be a big mistake). In
almost every project I've worked on, our purposes would be much better served
if a monotonic_clock were used instead. Rarely do we care what the epoch is.
What we do care about is timer reliability even when NTP (or some other
mechanism) is changing the clock. But that's just my experience.

Thanks for looking into this. I'm hoping for a resolution that doesn't make
<condition_variable> and <mutex> all but useless as provided by the standard
library sans modification. The boost team has already made some egregious
mistakes in this area.


-- 


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

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

[paolo dot carlini at oracle dot com]

------- Comment #7 from paolo dot carlini at oracle dot com  2010-02-04 18:02 -------
It seems to me that if DR887 is indeed resolved per the discussion in Santa
Cruz, thus the wait_for functions removed, the wait_until functions use
system_clock, then this issue could be immediately resolved. In other terms, I
would add [DR 887] to the Subject and suspend. Agreed?


-- 


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

[Bug libstdc++/41861] [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|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-02-05 12:53:09
               date|                            |


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

[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