From owner-freebsd-hackers@freebsd.org Wed Feb 22 15:46:18 2017 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B58BCE90AE for ; Wed, 22 Feb 2017 15:46:18 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 082E176D for ; Wed, 22 Feb 2017 15:46:17 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 09f31b96-f916-11e6-95b5-6dfd7dbb0ee5 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 09f31b96-f916-11e6-95b5-6dfd7dbb0ee5; Wed, 22 Feb 2017 15:46:14 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v1MFk5IB007865; Wed, 22 Feb 2017 08:46:05 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1487778365.73144.144.camel@freebsd.org> Subject: Re: Absolute timeouts and clock adjustments From: Ian Lepore To: Eric van Gyzen , Sebastian Huber , FreeBSD Date: Wed, 22 Feb 2017 08:46:05 -0700 In-Reply-To: <1ff4d78a-a157-53c5-af7e-b516bc1b6187@FreeBSD.org> References: <58AD5802.30908@embedded-brains.de> <1ff4d78a-a157-53c5-af7e-b516bc1b6187@FreeBSD.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 15:46:18 -0000 On Wed, 2017-02-22 at 09:19 -0600, Eric van Gyzen wrote: > On 02/22/2017 03:21, Sebastian Huber wrote: > > > > Hello, > > > > I try to figure out how the timeout mechanisms work in current > > FreeBSD. My > > interpretation (which could be completely wrong) of POSIX is > > something like this > > should happen: > > > > now 2017-02-22 > > sem_timedwait(s, 2023-12-13) > > external entity adjusts time to 2050-01-01 > > timeout of sem_timedwait() occurs due to the time adjustment > This is correct. > > > > > Inside the kernel all absolute timeouts seem to use the uptime. The > > sem_timedwait() seems to end up eventually in: > > > > /* > >  * Put thread into sleep state, before sleeping, check if > >  * thread was removed from umtx queue. > >  */ > > static inline int > > umtxq_sleep(struct umtx_q *uq, const char *wmesg, struct > > abs_timeout *abstime) > > { > >     struct umtxq_chain *uc; > >     int error, timo; > > > >     uc = umtxq_getchain(&uq->uq_key); > >     UMTXQ_LOCKED_ASSERT(uc); > >     for (;;) { > >         if (!(uq->uq_flags & UQF_UMTXQ)) > >             return (0); > >         if (abstime != NULL) { > >             timo = abs_timeout_gethz(abstime); > >             if (timo < 0) > >                 return (ETIMEDOUT); > >         } else > >             timo = 0; > >         error = msleep(uq, &uc->uc_lock, PCATCH | PDROP, wmesg, > > timo); > >         if (error != EWOULDBLOCK) { > >             umtxq_lock(&uq->uq_key); > >             break; > >         } > >         if (abstime != NULL) > >             abs_timeout_update(abstime); > >         umtxq_lock(&uq->uq_key); > >     } > >     return (error); > > } > > > > The abs_timeout_gethz() returns the interval length in ticks of > > [abstime->cur, > > abstime->end]. Since the msleep() uses the uptime, does this mean > > that timeouts > > trigger not immediately due to time adjustments in FreeBSD? > This is also correct.  The sleep will not be affected by the clock > adjustment.  > This is contrary to POSIX. > > Note that CentOS 6 (Linux 3.10) behaves the same way.  Fedora 24 > (Linux 4.8)  > behaves according to POSIX.  I don't know when this changed.  I also > don't know  > if it's configurable. > > By a curious coincidence, I'm working on adding a new > sem_clockwait_np()  > function to FreeBSD.  It allows the caller to specify the reference > clock and  > choose between absolute and relative mode.  In relative mode, the > remaining time  > can be returned. > > https://reviews.freebsd.org/D9656 > > My changes will not make sem_timedwait() comply with POSIX, but they > will let  > the caller use CLOCK_MONOTONIC and avoid the issue. > > Eric Using CLOCK_MONOTONIC doesn't avoid the issue, it just explicitly asks for the current behavior.  If the behavior you need is to wake up when CLOCK_REALTIME exceeds some value, you're still screwed. It would be easy enough to fix the current behavior by adding something like "if (timo > hz) timo = hz;" to the existing loop so that CLOCK_REALTIME gets re-checked once a second. -- Ian