https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91906
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> --- Author: redi Date: Mon Dec 2 16:23:14 2019 New Revision: 278904 URL: https://gcc.gnu.org/viewcvs?rev=278904&root=gcc&view=rev Log: libstdc++: Fix try_lock_until and try_lock_shared_until on arbitrary clock This is the equivalent to PR libstdc++/91906, but for shared_mutex. A non-standard clock may tick more slowly than std::chrono::steady_clock. This means that we risk returning false early when the specified timeout may not have expired. This can be avoided by looping until the timeout time as reported by the non-standard clock has been reached. Unfortunately, we have no way to tell whether the non-standard clock ticks more quickly that std::chrono::steady_clock. If it does then we risk returning later than would be expected, but that is unavoidable without waking up periodically to check, which would be rather too expensive. François Dumont pointed out[1] a flaw in an earlier version of this patch that revealed a hole in the test coverage, so I've added a new test that try_lock_until acts as try_lock if the timeout has already expired. [1] https://gcc.gnu.org/ml/libstdc++/2019-10/msg00021.html 2019-12-02 Mike Crowe <m...@mcrowe.com> Fix try_lock_until and try_lock_shared_until on arbitrary clock * include/std/shared_mutex (shared_timed_mutex::try_lock_until) (shared_timed_mutex::try_lock_shared_until): Loop until the absolute timeout time is reached as measured against the appropriate clock. * testsuite/30_threads/shared_timed_mutex/try_lock_until/1.cc: New file. Test try_lock_until and try_lock_shared_until timeouts against various clocks. * testsuite/30_threads/shared_timed_mutex/try_lock_until/1.cc: New file. Test try_lock_until and try_lock_shared_until timeouts against various clocks. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/shared_mutex
