[RFC 2/2] Add steady_clock support to condition_variable

Jonathan Wakely jwakely@redhat.com
Mon Jul 6 13:54:00 GMT 2015


On 06/07/15 13:55 +0100, Mike Crowe wrote:
>If __gthread_cond_timedwaitonclock is available it can be used it to fix
>part of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861 by supporting
>std::chrono::steady_clock properly with std::condition_variable.
>
>This means that code using std::condition_variable::wait_for or
>std::condition_variable::wait_until with std::chrono::steady_clock is no
>longer subject to timing out early or potentially waiting for much
>longer if the system clock is changed at an inopportune moment.
>
>If __gthread_cond_timedwaitonclock is available then
>std::chrono::steady_clock is deemed to be the "best" clock available
>which means that it is used for the relative wait_for calls and absolute
>wait_until calls that aren't choosing to use std::chrono::system_clock.
>Calls explicitly using std::chrono::system_clock continue to use
>CLOCK_REALTIME.
>
>If __gthread_cond_timedwaitonclock is not available then
>std::chrono::system_clock is deemed to be the "best" clock available
>which means that the previous suboptimal behaviour remains.

>From a quick glance this looks like a good change. As I said in my
other mail about the gthr-posix.h changes, it might be better to keep
this change to libstdc++ rather than splitting it across libstdc++ and
libgcc's gthr-posix.h

Do you have a copyright assignment in place for GCC contributions?




More information about the Gcc-patches mailing list