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