> 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. -- DE
