From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108154 invoked by alias); 26 Nov 2018 15:35:52 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 108140 invoked by uid 89); 26 Nov 2018 15:35:51 -0000 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 Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (217.72.192.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 26 Nov 2018 15:35:50 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MwPjf-1fZtSO3cY9-00sLzQ; Mon, 26 Nov 2018 16:35:45 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id 4188FA80587; Mon, 26 Nov 2018 16:35:45 +0100 (CET) Date: Mon, 26 Nov 2018 15:35:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Cc: "James E. King III" Subject: Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early Message-ID: <20181126153545.GM30649@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com, "James E. King III" References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FN+gV9K+162wdwwF" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-SW-Source: 2018-11/txt/msg00187.txt.bz2 --FN+gV9K+162wdwwF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2296 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" Content-length: 833 -----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--