From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21355 invoked by alias); 26 Nov 2018 15:47:55 -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 21341 invoked by uid 89); 26 Nov 2018 15:47:55 -0000 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 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with SMTP; Mon, 26 Nov 2018 15:47:53 +0000 Received: (qmail 55369 invoked by uid 99); 26 Nov 2018 15:47:52 -0000 Received: from mail-relay.apache.org (HELO mailrelay1-lw-us.apache.org) (207.244.88.152) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Nov 2018 15:47:52 +0000 Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 108713B9C for ; Mon, 26 Nov 2018 15:47:51 +0000 (UTC) Received: by mail-lf1-f49.google.com with SMTP id p6so13919650lfc.1 for ; Mon, 26 Nov 2018 07:47:50 -0800 (PST) MIME-Version: 1.0 References: <20181126153545.GM30649@calimero.vinschen.de> In-Reply-To: <20181126153545.GM30649@calimero.vinschen.de> From: "James E. King III" Date: Mon, 26 Nov 2018 15:47:00 -0000 Message-ID: Subject: Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early To: cygwin@cygwin.com Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-11/txt/msg00188.txt.bz2 On Mon, Nov 26, 2018 at 10:35 AM Corinna Vinschen 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