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