Re: Linux nanosleep investigation.

[Kaz Kylheku <kaz at ashi dot footprints dot net>]

On Tue, 15 Feb 2000, Andrea Arcangeli wrote:

> Could you give a try to this patch that I developed in the last hours?
> Beware: it's untested but looks ok. Against 2.2.14:

In the last hours? I went to ftp.ca.linux.org, and the file has a Feb 15 1999
date on this server! That confused me for a few seconds.

> 	ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.14/nanosleep-1.gz
> 
> My approch is not that far from what I read now in your email you
> quoted while including me into the CC list (I think it's been wrote by
> Kaz).

Thanks for the patch. 

There is one remaining unsolvable issue.  The expiry time is still adjusted up
by one jiffy if the wait is non-zero (and larger than the threshold for doing a
CPU delay fine wait):

 	expire = timespec_to_jiffies(&t) + (t.tv_sec || t.tv_nsec);

This *cannot* be fixed in the kernel. Because the Single UNIX Specification,
and I assume POSIX as well, clearly state that the nanosleep function must not
wake up until the specified time has passed. The wait can be rounded up, but
not down!  Breaking this would break nanosleep's compliance with the applicable
standards.

This ultimately means that pthread_cond_timedwait cannot be implemented
*well* in terms of nanosleep.  Users writing quasi-real-time software
expect that when they tell pthread_cond_timedwait to wake up at absolute
time T, that the wakeup will take place at that time rather than at T +
1/HZ, even though the standard is lenient in this regard. (Provided that
the time is exactly expressible in the underlying time quanta, otherwise a
rounding up is suffered). It's acceptable for pthread_cond_timedwait to
wake up late, but only for scheduling reasons or due to the non-real-time
nature of the OS; i.e. another thread had to be run, or interrupts were
disabled too long.

What might ultimately help in the LinuxThreads implementation would be a
nanosleep-like system call which takes an absolute time timespec parameter.

Until we get such a call, what we could do is compensate by fudging the input
timespec value. For example, if the timespec is greater than or equal to one
jiffy, LinuxThreads could decrease it by one jiffy.