From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 943 invoked by alias); 29 Nov 2018 22:39:05 -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 932 invoked by uid 89); 29 Nov 2018 22:39:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.9 required=5.0 tests=BAYES_00,ENV_AND_HDR_SPF_MATCH,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=ham version=3.3.2 spammy=uploaded 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; Thu, 29 Nov 2018 22:39:02 +0000 Received: (qmail 78582 invoked by uid 99); 29 Nov 2018 22:39:00 -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; Thu, 29 Nov 2018 22:39:00 +0000 Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id D6716F7C for ; Thu, 29 Nov 2018 22:38:59 +0000 (UTC) Received: by mail-lj1-f176.google.com with SMTP id u6-v6so3251651ljd.1 for ; Thu, 29 Nov 2018 14:38:59 -0800 (PST) MIME-Version: 1.0 References: <20181126153545.GM30649@calimero.vinschen.de> <20181126164657.GN30649@calimero.vinschen.de> <20181129101821.GZ30649@calimero.vinschen.de> In-Reply-To: <20181129101821.GZ30649@calimero.vinschen.de> From: "James E. King III" Date: Thu, 29 Nov 2018 22:39: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/msg00250.txt.bz2 On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen 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 > > > 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