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-cygwin@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