On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen <corinna-cyg...@cygwin.com> wrote: > > On Nov 26 17:46, Corinna Vinschen wrote: > > On Nov 26 10:47, James E. King III wrote: > > > 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: > > > > [...] > > > > 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? > > > > Au contraire: > > > > - The end time you're waiting for is rounded *up*. > > - The current time is rounded *down* > > - So end time - current time is always bigger than required > > on the 100ns level. > > > > Make sense? > > I created a patch and uploaded new developer snapshots to > https://cygwin.com/snapshots/ Please give them a try. > > > Thanks, > Corinna >
This fixed the issue for me. What's the best way to detect cygwin with this support? I see something around "has_precise_interrupt_time". I suppose that would be it? I need to make some changes in Boost.Thread to accomodate it. Thanks, 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