[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Short sleeps.
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
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
Mark 'Nurgle' Collins
Lead Author - Linux Game Programming (Premiere Press)
Author - Advanced AI Game Development (WordWare)
Email: firstname.lastname@example.org Phone: +44 7761 774 152
Email: email@example.com Spam: firstname.lastname@example.org