> On Oct 8, 2018, at 1:43 PM, enh <e...@google.com> wrote:
>> On Sat, Oct 6, 2018 at 12:09 PM Mike Crowe <theopengr...@mac.mcrowe.com> 
>> wrote:
>>> On Wednesday 12 September 2018 at 13:47:59 -0700, Tom Cherry wrote:
>>>> On Wed, Sep 12, 2018 at 11:56 AM Mike Crowe <theopengr...@mac.mcrowe.com> 
>>>> wrote:
>>>>> We (libc team for Android) have observed this problem too and have
>>>>> seen it cause issues on multiple occasions, enough times that we
>>>>> actually submitted a workaround that always converts the input
>>>>> timespec to CLOCK_MONOTONIC and waits with that clock[1].  Of course
>>>>> this only ameliorates the problem, but does not completely solve it,
>>>>> since there is still a period in time before the conversion to
>>>>> CLOCK_MONOTONIC happens, that if CLOCK_REALTIME changes abruptly,
>>>>> we're back to the same bad behavior as before.
>>>>> For this reason, we added pthread_cond_timedwait_monotonic_np() back
>>>>> in the P release of Android[2] along with equivalent functions for the
>>>>> rest of the timed waits.  I've also pushed various patches to libc++,
>>>>> one that builds upon these changes to our libc[3] and one that
>>>>> implements std::condition_variable from scratch, borrowing the
>>>>> implementation from our libc[4], however neither made progress.
>>>>> As for having a separate clock id parameter, we thought about that
>>>>> during the review of the above changes, but we both thought that 1)
>>>>> there's no strong reason to wait on any clock other than
>>>>> CLOCK_MONOTONIC for these functions and 2) the underlying futex
>>>>> implementation only allows CLOCK_REALTIME and CLOCK_MONOTONIC, so we'd
>>>>> have to do conversions in userspace and inevitably wait on
>>>>> CLOCK_MONOTONIC anyway, so it's best to be clear and only give
>>>>> CLOCK_MONOTONIC as an option.

I'd rather see the clock id passed in as it's more generally useful.  By using 
_monotonic, it implies that there are only 2 clocks that matter, the default 
clock is widely chosen wrong, and that you can't change it on a per-thread 
basis, not that you want other clock options.  I can't change the c++ standard, 
but it doesn't seem like an elegant solution to add a lot of duplicate 
_monotonic functions that serve only the monotonic clock.  I admit, I am not 
familiar with the history behind this.

It is conceivable that you could wait on more than just the real-time and 
monotonic clocks.  FreeBSD, at least via pthread_condattr_setclock(), allows 
you to wait on _REALTIME, _VIRTUAL, _PROF, and _MONOTONIC clocks.  In addition 
to those, it defines several more.  Solaris defines 6 clocks, though I'm not 
sure how many are waitable.


Reply via email to