Absolute timeouts and clock adjustments

Sebastian Huber sebastian.huber at embedded-brains.de
Wed Feb 22 09:21:21 UTC 2017


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

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 
     struct umtxq_chain *uc;
     int error, timo;

     uc = umtxq_getchain(&uq->uq_key);
     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) {
         if (abstime != NULL)
     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?

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 at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

More information about the freebsd-hackers mailing list