C++11's std::condition_variable, std::timed_mutex and
std::recursive_timed_mutex support waiting with a timeout specified using
an arbitrary clock. It's common to use std::chrono::steady_clock (which
corresponds to CLOCK_MONOTONIC) or std::chrono::system_clock (which
corresponds to CLOCK_REALTIME) for these waits, and other clocks end up
being converted to one of those when performing the wait.
Unfortunately, I don't believe that it's possible to implement these on top
of the pthread equivalents correctly for std::chrono::steady_clock (i.e.
CLOCK_MONOTONIC) since:
1. pthread_mutex_timedlock only supports a time measured against
CLOCK_REALTIME.
2. The clock used for pthread_cond_timedwait must be specified when the
condition variable is created by pthread_cond_init. The clock to be used
for future waits is not known at the point that the
std::condition_variable constructor is called.
I'm most interested in the std::condition_variable case. since I have code
that wants to wait using std::chrono::steady_clock.
There are a number of possible workarounds for these. I've described some
in a blog post[1] and in defect 0001164[2]. But, my favourite solution is
to introduce a variant of pthread_cond_timedwait that takes a an additional
clockid_t parameter:
int pthread_cond_timedwaitonclock(pthread_cond_t *cond,
pthread_mutex_t *mutex,
clockid_t clockid,
const struct timespec *abstimeout);
I've proposed[3] an implementation of this function for glibc (as
pthread_cond_timedwaitonclock_np) and it was suggested that I ought to
raise it here. (This led me to enter defect 0001164, but since that yielded
no response I've finally got round to writing this email too.)
The equivalent for mutex would probably be:
int pthread_mutex_timedlockonclock(pthread_mutex_t *mutex,
clockid_t clockid,
const struct timespec *abstimeout);
but I've not yet made any attempt to implement it in glibc.
Would making the C++ standard library implementable on top of POSIX be
considered a good enough reason to add such functions?
Are these functions generic enough or perhaps too generic? Android had a
pthread_cond_timedwait_monotonic function for a while, but deprecated it
when they added support for pthread_condattr_setclock.
Thanks.
Mike.
[1]
https://randombitsofuselessinformation.blogspot.com/2018/06/its-about-time-monotonic-time.html
[2] http://austingroupbugs.net/view.php?id=1164
[3]
http://libc-alpha.sourceware.narkive.com/3ZPZzEOy/rfcv4-add-pthread-cond-timedwaitonclock-np#post1
