On Mon, Nov 26, 2018 at 10:35 AM Corinna Vinschen <corinna-cyg...@cygwin.com> wrote: > > On Nov 25 09:01, James E. King III wrote: > > I have isolated a problem in pthread_cond_timedwait when the condattr > > is used to set the clock type to CLOCK_MONOTONIC. In this case even > > though a target time point in the future is specified, the call > > returns ETIMEDOUT but a subsequent call to > > clock_gettime(CLOCK_MONOTONIC) shows the desired time point was not > > reached. > > > > $ gcc timed_wait_short.c -o timed_wait_short > > $ ./timed_wait_short.exe > > [...] > > begin: 521056s 671907500n > > target: 521056s 721907500n > > end: 521056s 721578000n > > ok: false > > > > I have attached the source code. > > Thanks for the testcase. The problem is this: > > The underlying implementation uses a Windows waitable time set to > implement the timeout. In case of a CLOCK_REALTIME timer, we can use > the given absolut timestamp in 100ns resolution for the timer. > > On the other hand, the CLOCK_MONOTONIC timer is not running in absolut > time but uses the hi-res timestamps generated by QueryPerformanceCounter. > The perf counter uses an arbitrary "ticks per second" unit which is > converted to nsecs on the fly on the POSIX API level. However, perf > counters are not waitable objects, only waitable timers are, so we have > to use the perf timer values to prime a waitable timer evetually. > > The side effect is that we have to use relative offset under the hood as > soon as the base timer is CLOCK_MONOTONIC, since there's no direct > relation to the absolute system time as used by the waitable timer in > absolute mode. > > Combine this with the inaccuracy of the Windows waitable timer and wait > functions in general(*) and you know what uphill battle accuracy is in > this scenario. > > Having said that, I don't have a *good*, reliable solution to this > problem. > > At the moment I only have an *ugly* idea: We can always add the > coarsest resolution of the wait functions (typically 15.625 ms) to the > relative timeout value computed from the absolute timeout given to > pthread_cond_timedwait. In my testing this is sufficient since the > difference between target and actual end time is always < 15ms, in > thousands of runs. > > Thoughts? > > > Thanks, > Corinna > > (*) > https://docs.microsoft.com/en-us/windows/desktop/Sync/wait-functions#wait-functions-and-time-out-intervals > > -- > Corinna Vinschen > Cygwin Maintainer
Some thoughts: https://cygwin.com/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/thread.cc;h=0bddaf345d255ae39187458dc6d02b1b4c8087c1;hb=HEAD#l2546 In pthread_convert_abstime, line 2564, care is taken to adjust for rounding errors. At line 2574, the rounding is not accounted for when adjusting for a relative wait because it is a monotonic clock. Wouldn't that rounding error cause it to wait less time? - Jim -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
