Absolute timeouts and clock adjustments

[Sebastian Huber]

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

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?

-- 
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.