This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]