X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:content-type; q=dns; s=default; b=e6w6r8R
	0b+H9wKzttZd55xQF931uFWog0B5KlXKf35gx6osgp1y3ZPZ2c7QWejYV26zeN0I
	gPv49KjQUthanIN29SPwZqJWoUQHgWsloe/WHFVdnLVWuuQDy5C6NongzGXjw+Ww
	0T6L0xy1aOFwxwKmSNTLMEZ8T62wRHjOcpR8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:content-type; s=default; bh=kPulEzrB+J6AB
	yjlFxpHwtE/i64=; b=vnOa+H+KVIeePl6VkGlnNfewvSXVgMaWk5PoSNtbsTWK4
	n+M60JpRVBoB3BZVfie0YFF1xKJa2gKkZjE2pL8Jlj3yK73hZn1KvZiIkx1Ohg24
	YCdcSzuujZy4sq/jtiShQoTDU6cLZlxxndIhRknhK3rkhFeLyjBzwXW/NjeXTg=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-10.0 required=5.0 tests=AWL,BAYES_00,ENV_AND_HDR_SPF_MATCH,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=ham version=3.3.2 spammy=UD:cygwin.com, cygwincom, cygwin.com, Jim
X-HELO: mail.apache.org
MIME-Version: 1.0
References: <CAOWZHxdTpDD6LLVctvjFQWqQMd9cex7pp-s1YYaMAdtGECy3Yw AT mail DOT gmail DOT com> <20181126153545 DOT GM30649 AT calimero DOT vinschen DOT de>
In-Reply-To: <20181126153545.GM30649@calimero.vinschen.de>
From: "James E. King III" <jking AT apache DOT org>
Date: Mon, 26 Nov 2018 10:47:38 -0500
Message-ID: <CAOWZHxdmOeQ7o6099PERwq-FbFbdYLLm43JfR5iQm-HtfP90aw@mail.gmail.com>
Subject: Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset="UTF-8"

On Mon, Nov 26, 2018 at 10:35 AM Corinna Vinschen
<corinna-cygwin AT cygwin DOT 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