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 -- Corinna Vinschen Cygwin Maintainer
signature.asc
Description: PGP signature
