https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861
--- Comment #9 from Mike Crowe <mac at mcrowe dot com> --- It seems that there's been lots of talk about this but no firm solution. Here's some interesting links: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2999.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4486.html (search for "887") https://www.redhat.com/archives/posix-c++-wg/2009-July/msg00002.html (search for "887") https://github.com/cplusplus/LWG/blob/master/xml/issue0887.xml To me they seem to boil down to three points of view: 1. The current implementation of converting all other clocks to the system_clock is acceptable behaviour. Unfortunately this is racey when the system clock is changed and could cause the caller to wait for far longer than requested. 2. Implementers should add an extra constructor parameter (or perhaps template parameter) to condition_variable to allow the master clock for the condition_variable to be configured. All clocks would then be converted to this clock. This would allow the client code to express its intent but it seems ugly to require platform-specific code to make the standard behaviour actually work. 3. condition_variable should support wait_until using at least steady_clock (CLOCK_MONOTONIC) and system_clock (CLOCK_REALTIME.) Relative wait operations should use steady_clock. User-defined clocks should probably convert to steady_clock. I believe that only option 3 makes any sense but this requires an equivalent to pthread_cond_timedwait that supports specifying the clock. The glibc implementation of such a function would be straightforward.
