Re: IOLockSleepDeadline example in docu is wrong (won't compile)
Re: IOLockSleepDeadline example in docu is wrong (won't compile)
- Subject: Re: IOLockSleepDeadline example in docu is wrong (won't compile)
- From: Shaun Wexler <email@hidden>
- Date: Wed, 5 Sep 2007 14:10:40 -0700
On Sep 5, 2007, at 12:18 PM, Terry Lambert wrote:
So as someone suggested, I'm now using IOSleep instead, which
seems to do exactly what I want to do (why would I want to do
IODelay? Where is the advantage of wasting plenty of CPU time for
a couple of ms - a spin lock is maybe meaningful if you sleep for
a couple of ns or us, because there the sleep/wake-up would take
longer than the actual time to sleep, but if you sleep more than
one ms, I guess it's fine to real put the thread to sleep).
The general reason for using IODelay(), according to the Kernel
Programming Guide at:
<http://developer.apple.com/documentation/Darwin/Conceptual/
KernelProgramming/KernelProgramming.pdf>
is:
IODelay, provided by the I/O Kit, abstracts a timed spin. If you
are delaying for a short
period of time, and if you need to be guaranteed that your wait
will not be stopped
prematurely by delivery of asynchronous events, this is probably
the best choice. If you
need to delay for several seconds, however, this is a bad choice,
because the CPU
that executes the wait will spin until the time has elapsed,
unable to handle any other
processing.
So personally, I'd use it if I were a hardware manufacturer who had
made a cost trade-off to reduce the COGS on my hardware by skimping
on FIFO space, and needed a guaranteed service latency so that it
didn't drop data. And I'd hope that if I did this, the hardware
was intended to have only intermittent use, so that it didn't
become a performance problem for everything else on the machine.
So, for example, a QIC-40/QIC-80 floppy tape drive attached to a
floppy controller with a 16 byte FIFO would probably qualify (but
there are other cleverer tricks you could do instead with that
particular hardware to keep it streaming; the BSDI driver was a
thing of beauty).
IODelay could have been implemented as an inline spin loop which
reads the timebase registers, but it was not, thus the documentation
is somewhat misleading.
There is no underlying difference between IOSleep and IODelay
functions, except for the granularity of their argument (mS vs µS).
They both call down to clock_delay_until(), which sleeps the calling
thread if preemption is enabled or the sleep time is longer than the
duration of (8x) context switches, etc.
Use IODelay if you need to sleep/spin for times and/or granularities
less than 1 ms, else use IOSleep.
--
Shaun Wexler
MacFOH
http://www.macfoh.com
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden