Subj : Re: pthread_cond_timedwait problems
To   : comp.programming.threads
From : steve
Date : Tue Aug 16 2005 10:33 pm

In article <1124183800.195256.246950@o13g2000cwo.googlegroups.com>,
markh@compro.net <markh@compro.net> wrote:
>
>I meant the timespec member. I just ignorantly assumed since the
>structure used had a nsec  member, that I would get that (or close)
>resolution. I understand better  now what is happening except for one

There's a reasonable discussion of this issue in the POSIX standard, but
nobody but implementors reads that. (Only 1/2 kidding.)

>thing. I consistantly get results I might have originally expected when
>using delays shorter than HZ. The below are using a 2.6.12.4 kernel
>BTW. What is really happening there?

That's a feature of Linux that attempts to more closely match your
requested time if it's much less than a single system tick.

Due to the way that timing subsystems in *NIX operating systems work, a
timeout will fire on the clock tick, which will occur at some regular
period (often 10ms, sometimes 1ms, occasionally some completely odd
value).

>Attempting  delay of   100 nsec (0 usecs)
>gettimeofday returned  1124183504 sec   963619    usec
>New delay struct       1124183504 sec   963619100 nsec
>Actual usec delay from timer =  11 usecs
>
>Attempting  delay of   1000 nsec (1 usecs)
>gettimeofday returned  1124183504 sec   963684    usec
>New delay struct       1124183504 sec   963685000 nsec
>Actual usec delay from timer =  5 usecs
>
>Attempting  delay of   10000 nsec (10 usecs)
>gettimeofday returned  1124183504 sec   963723    usec
>New delay struct       1124183504 sec   963733000 nsec
>Actual usec delay from timer =  6 usecs

This one here is officially a POSIX violation:  An implementation is
not allowed to delay any less than the passed-in value.  It may delay
longer, though.

>Attempting  delay of   100000 nsec (100 usecs)
>gettimeofday returned  1124183504 sec   963796    usec
>New delay struct       1124183504 sec   963896000 nsec
>Actual usec delay from timer =  1960 usecs
>
>Attempting  delay of   1000000 nsec (1000 usecs)
>gettimeofday returned  1124183504 sec   965802    usec
>New delay struct       1124183504 sec   966802000 nsec
>Actual usec delay from timer =  1955 usecs

This one is expected.  Because implementations aren't allowed to return
early on sleeps, they must round to the *next* tick after the time would
elapse.  And because it's possible for the system call requesting a
9.99ms delay to come in a microsecond before the tick, Linux (and most
other implementations) simply rounds up.

If you think about it, given a random distribution of sleep request
arrival times all asking for exactly one clock tick of time, and that
awakens can only be scheduled on clock ticks, the average if you round
to nearest will be that half of the timers fire early.  In real-time
systems, that is often undesirable, so the choice was made to require
the full-length to have elapsed.
-- 
Steve Watt KD6GGD  PP-ASEL-IA          ICBM: 121W 56' 57.8" / 37N 20' 14.9"
 Internet: steve @ Watt.COM                         Whois: SW32
   Free time?  There's no such thing.  It just comes in varying prices...

.