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=xtsSbFa
	2Wn7isRzW5iRPJNLRA8kNn08axIFWybeZ94QcNwz/xZiobl+qihnJhegzVUnBGe/
	vC1Wxd4dE6eIiiQ1YLaFcLep2JIqfTnAn1ZfY1lsI65n6jSA+CueKnq/mj7ERs6w
	FC+9QB4CFGf7oW0pvBcYSL472+XcZ8r+jYpc=
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=wghsQG7X/fzPG
	/cijLenc7IsZbE=; b=vvcmjuec4aJr8fpG4rYmnQTT7jOR11/JdyrW3dI6VEPky
	wlq/nYjTLXn8tJno5b+kmfPd+3MJlS0cJZXufZ1aQwsbqk/AppFI+X/KYdeWh23S
	3bS02hUvtNDQFpAej1qVJDdDHo8m457aYDJpvFkKolY7sOCp1PpTLZWN3jkX9o=
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=-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
MIME-Version:	1.0
References:	<CAOWZHxdTpDD6LLVctvjFQWqQMd9cex7pp-s1YYaMAdtGECy3Yw AT mail DOT gmail DOT com> <20181126153545 DOT GM30649 AT calimero DOT vinschen DOT de> <CAOWZHxdmOeQ7o6099PERwq-FbFbdYLLm43JfR5iQm-HtfP90aw AT mail DOT gmail DOT com> <20181126164657 DOT GN30649 AT calimero DOT vinschen DOT de> <20181129101821 DOT GZ30649 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20181129101821.GZ30649@calimero.vinschen.de>
From:	"James E. King III" <jking AT apache DOT org>
Date:	Thu, 29 Nov 2018 17:38:47 -0500
Message-ID:	<CAOWZHxf+en-Nw20jOeeBu-TXBio07ai5ecJk2bvWDPtD0vqKFQ@mail.gmail.com>
Subject:	Re: pthread_cond_timedwait with setclock(CLOCK_MONOTONIC) times out early
To:	cygwin AT cygwin DOT com

On Thu, Nov 29, 2018 at 5:18 AM Corinna Vinschen
<corinna-cygwin AT cygwin DOT com> 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
> > > <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:
> > > > [...]
> > > > 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

- Raw text -