[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