Date: Wed, 22 Feb 2017 10:21:06 +0100 From: Sebastian Huber <sebastian.huber@embedded-brains.de> To: FreeBSD <freebsd-hackers@freebsd.org> Subject: Absolute timeouts and clock adjustments Message-ID: <58AD5802.30908@embedded-brains.de>
next in thread | raw e-mail | index | archive | help
Hello,
I try to figure out how the timeout mechanisms work in current FreeBSD.=20
My interpretation (which could be completely wrong) of POSIX is=20
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
Inside the kernel all absolute timeouts seem to use the uptime. The=20
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=20
*abstime)
{
struct umtxq_chain *uc;
int error, timo;
uc =3D umtxq_getchain(&uq->uq_key);
UMTXQ_LOCKED_ASSERT(uc);
for (;;) {
if (!(uq->uq_flags & UQF_UMTXQ))
return (0);
if (abstime !=3D NULL) {
timo =3D abs_timeout_gethz(abstime);
if (timo < 0)
return (ETIMEDOUT);
} else
timo =3D 0;
error =3D msleep(uq, &uc->uc_lock, PCATCH | PDROP, wmesg, timo);
if (error !=3D EWOULDBLOCK) {
umtxq_lock(&uq->uq_key);
break;
}
if (abstime !=3D NULL)
abs_timeout_update(abstime);
umtxq_lock(&uq->uq_key);
}
return (error);
}
The abs_timeout_gethz() returns the interval length in ticks of=20
[abstime->cur, abstime->end]. Since the msleep() uses the uptime, does=20
this mean that timeouts trigger not immediately due to time adjustments=20
in FreeBSD?
--=20
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG=
.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?58AD5802.30908>