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:date:from:to:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=YIwgUbS0mU55uGRX8nU3BTWrzOf/bEjYoeJ6btMClFX0avN6aVMg/
	15ix82i7DUUe8v8Cb6cH7r04DUd58yaasNCsWwCtmM5Qt8vWFSUkM8BGTSuzL2Xp
	1Vqq9XZGLxphT4LllXwpCRnIRkDMZXJ8RPvuX+OM1VB+GRd0HlutVY=
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:date:from:to:cc:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=CpoQAU9l2XWXlHsbZwcvxG/Ftq0=; b=H4pifBeuSPLLQIGgtRF5BBq0/VZC
	RMMwx2bNJC9iFgL/LgjnfVHRKfVvy6XIVS+xaN0dYh0unddaVVbju7qOnoS9DSUh
	o7mcK5ddbtraSoQoKZ2HQzf5SuAY9PTIpvaZbLLsB+6VzoBkVfP6C+JGubUc9uvg
	c8auRwhmL6xUcA8=
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=-100.9 required=5.0 tests=BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=H*Ad:D*apache.org, timer, thousands, battle
X-HELO:	mout.kundenserver.de
Date:	Mon, 26 Nov 2018 16:35:45 +0100
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Cc:	"James E. King III" <jking AT apache DOT org>
Subject:	Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early
Message-ID:	<20181126153545.GM30649@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com, "James E. King III" <jking AT apache DOT org>
References:	<CAOWZHxdTpDD6LLVctvjFQWqQMd9cex7pp-s1YYaMAdtGECy3Yw AT mail DOT gmail DOT com>
MIME-Version:	1.0
In-Reply-To:	<CAOWZHxdTpDD6LLVctvjFQWqQMd9cex7pp-s1YYaMAdtGECy3Yw@mail.gmail.com>
User-Agent:	Mutt/1.9.2 (2017-12-15)

--FN+gV9K+162wdwwF
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> $ gcc timed_wait_short.c -o timed_wait_short
> $ ./timed_wait_short.exe
> [...]
>  begin:     521056s  671907500n
> target:     521056s  721907500n
>    end:     521056s  721578000n
>     ok: false
>=20
> 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#wa=
it-functions-and-time-out-intervals

--=20
Corinna Vinschen
Cygwin Maintainer

--FN+gV9K+162wdwwF
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlv8EtEACgkQ9TYGna5E
T6DHQxAAlsbtmb4LF3Id4ICdHhxEL8txNjuNNRcewcvhcxing0eiptE3kXm14sPv
LxBjPYL1qpmUge7pSyPl4yy118Wcw8xJIxl9kmMh4DviIDh9GkPAURhumFL0ffds
P5HytuPLbXS79OsKgZvuugyxiAGHEeuqtlSYjXGO61ef+5widdQenngPBiNfDdez
g/n3dDlPZ07Q5jPJT3UCHV5i2Dj0u4imw5LpQ64YeYuCtxqueCraYTS3aFqzNSAg
G72YNN3Yt4t4Y/56gTfbzEmuPKPI6pG+os6bZqMcz5F3ZKASYDvbm2+nYAu4e/Qy
yIdzfITzGFiulRuVIWZY648xs6kvX2WZYNybQcaefzDY14WokuN/x33fFbj5RTLn
7Wl1FQioRUH8zsbg4rgGfc26Amq1BLT+uzKwUQkrdL/AYVz7l0oxbCTjG1gijBtx
EcuMYFH40c9HZLO3ZlkG9kFlsfckWVu/X9owQG1Fdocb045hj0VdVrFRikY8/g5m
Ca1qfrA2xGRbIaxPydfvnInxpE9Gv14bJOnhd0Ae0iUKtDtQjSciat4mny2UIQKz
ahPavIXB2Ql+42hTKeZWCpDv7izf+VS7l2Bt/4PPfR4lLX3KmM/jz39h/249Yo39
C3iAuYWdVg3sMCLUnGubwCID1rYA7xxI7k2ycJXU7ouiD41gJFU=
=nKsx
-----END PGP SIGNATURE-----

--FN+gV9K+162wdwwF--

- Raw text -