[vdr] Re: usleep question.

[Andreas Schultz <aschultz@cs.uni-magdeburg.de>]

On Sunday 07 April 2002 13:12, Carsten Koch wrote:
> AFAIK, the Linux scheduler interval is 10 ms
> and all usleep calls between usleep(1) and
> usleep(10000) have the same effect.
> So I wonder why we find usleep(1) calls so
> often. If the scheduler interval will ever
> be reduced in future operating system versions,
> will that not turn programs that use these
> fantastic low usleep values into CPU-hogs
> or even make them fail because they really
> depend of the fact that usleep(1) sleeps for
> longer than a MICROsecond?
> After all, there are a million microseconds in
> a second! ;-)
>
> Also, the usleep man page says:
>        This function is obsolete.
>        Use nanosleep(2) or setitimer(2) instead.
> And the nanosleep man page says:
>        Compared  to ... usleep(3),  nanosleep
>        ... provides higher timing resolution
>
> Can anyone clarify what exactly is going on?

from glibc-2.2.5, ./sysdeps/unix/sysv/linux/usleep.c

int
usleep (useconds_t useconds)
{
  struct timespec ts = { tv_sec: (long int) (useconds / 1000000),
                         tv_nsec: (long int) (useconds % 1000000) * 1000ul };

  return __nanosleep (&ts, NULL);
}

so, we are using nanosleep ;-)
usleep(1) is used to yield the current timeslice to other processes as we have 
no immediate use for it or we are waiting for another process to finish some 
task. The selection of 1ms is arbritraty and could probably also replace by 
sched_yield(). usleep is not used as timing function and we do not reley on 
accurate timing.

While looking into this, i also found something interresting about this, from 
linux/kernel/times.c:

asmlinkage long sys_nanosleep(struct timespec *rqtp, struct timespec *rmtp)
{
    .....
                /*
                 * Short delay requests up to 2 ms will be handled with
                 * high precision by a busy wait for all real-time processes.
                 *

This explains the lookup's when running under real-time scheduling. The 
scheduler will not allow other process to run, therefore completly blocking 
out all other processes.

Andreas