This is the mail archive of the libc-alpha@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Linux nanosleep investigation.


On Wed, 16 Feb 2000, Andrea Arcangeli wrote:

> I think one possible way to be more precise in nanosleep for RT tasks
> could be to not add the additional jiffy to the schedule_timeout call, and
> then to usleep for the remaining time if no signal happened meanwhile (we
> now know the remaining time with my patch doing after-before). Looks
> doable in my way. Anyway I don't think that would be that useful (sure it
> won't be useful to non RT users). If you want to sleep longer than 10 msec
> you don't care to wakeup 5msec after as far I can tell. Could you explain
> me exactly why the 5msec of additional sleep will make a difference for
> you?

LinuxThreads uses nanosleep to implement the pthread_cond_timedwait function.
The pthread_cond_timedwait function takes an absolute time. You specify the
timespec when the thread should wake up; but nanosleep consistently causes it
to wake up one jiffy later than that time. With pthread_cond_timedwait,
the relative wait amount doesn't matter; what is important is to wake up at
the specified time, if possible.

With pthread_cond_timedwait you can do things like.

    for (;;) {
	/* record the current time */
	/* do some processing */
	/* sleep until recorded time + delta */
    }

As long as the processing is less than delta, and delta is exactly
representible in the clock tick units (jiffies), and the time between
sleeping and recording the time again does not exceed a clock tick, this
program will wake up every delta period in a predictable way.

This won't work properly if the sleep arbitrarily extends the delta by a whole
clock tick!

I'm not even convinced that in the case of pthread_cond_timedwait it is
desirable at all to support the micro-fine delays that nanosleep does for small
timeout values. I can't speak for all users, but I don't see it being used
as a delay function; it's more useful for scheduling things to happen at
predetermined times. For example, you can readily use it to implement a timer
thread that performs callouts.

So that is sort of the vague rationale, or my version of it. ;)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]