Re: Short sleeps.

[Mark Collins <me@thisisnurgle.org.uk>]

On Friday 11 January 2002  8:19 am, you wrote:
> Yes - sure there is an equivelant - but that's a busy-wait which
> prevents other processes from running - something that I explicitly
> wish to avoid.
>
> Linux's nanosleep() will do busy-waits for up to 2 milliseconds - or
> you can do as you did by looping on gettimeofday or something and get
> microsecond precision busy-waits.
>
> However, I want to actually give up the CPU while I'm waiting.

Well, that could be a problem with such high-resolution sleeps, and could be 
a wasted effort (although the loopback idea sounds good...).

When you give control to another process, that process could block for <x> 
milliseconds, then the schedular passes controll to another process, which 
blocks for <y> milliseconds and so on.

Amd, looking at my FIrst Edition of Linux Device Drivers, on page 137, there 
is mention of the udelay() function, which is pretty high resolution, BUT, it 
blocks. The books says that there are no functions (or fails to mention 
functions) for such high resolution delays.

Of course, this is quite an old book, and things might have changed since 
then...

I just tried a very simple program, which uses sleep(), which looked like it 
had no delay. I'm not sure if this blocks, but if you pass 0 as an argument, 
it MAY continue performing tasks in the schedule queue for one cycle. Stick 
that in a loop like the one I mentioned eariler, and you may be in luck...

I don't have the glibc source handy (maybe someone who does would like to 
check this), but I'd hazard a guess that the sleep() functions does the 
sleep, then check the delay. If so, problem solved... if not, back to the 
drawing board...

===
Mark 'Nurgle' Collins
Lead Author - Linux Game Programming (Premiere Press)
Author - Advanced AI Game Development (WordWare)
Email: me@thisisnurgle.org.uk	Phone: +44 7761 774 152
Email: nurgle@isyourgod.net	Spam: spam@thisisnurgle.org.uk