https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91906
Bug ID: 91906
Summary: std::timed_mutex::try_lock_until may not wait for
timeout to expire when called with user-defined clock
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mac at mcrowe dot com
Target Milestone: ---
The clock-agnostic overload of std::timed_mutex::try_lock_until may return
false before the timeout (as measured against that clock) has expired.
The clock-agnostic std::timed_mutex::try_lock_until overload converts the
timeout to a relative duration and adds it to system_clock before calling
the corresponding _M_try_lock_until overload that waits for that absolute
timeout measured against system_clock before returning.
There's no guarantee that the non-standard clock has reached the timeout
time when the system_clock absolute timeout has expired.
The clock-agnostic std::timed_mutex::try_lock_until ought to loop waiting
for the specified timeout time to be reached.
Of course, the non-standard clock may be ticking faster than
std::chrono::system_clock, but unfortunately there's no low-overhead way to
determine that. In this case try_lock_until will return later than
expected, but that's permitted behaviour.
(I'm preparing a patch to fix this as part of a series that includes the fix
for bug 78237.)
