Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early

["James E. King III" <jking@apache.org>]

On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen
<corinna-cygwin@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-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
>

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