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: Terry Lambert <email@hidden>
- Date: Wed, 5 Sep 2007 12:18:50 -0700
On Sep 5, 2007, at 1:34 AM, Markus Hanauska wrote:
Okay, but in that case, could Apple please update their webpage to
represent the code in a way that compiles. Many people tried to tell
me, that this depends on the system version, however, I checked for
10.2, 10.3 and 10.4 and it's always the same, at least to the SDKs
found in my Xcode installation.
Please file a bug report with <http://bugreport.apple.com> or contact
DTS about any problems you have with examples; this mailing list is an
inappropriate venue for reports against Apple web sites. All
complaining here does is get you frustrated people who can't do
anything about your problem for you because you failed to file a bug
report that they can then hang the work off of to justify their time
spent as service to a customer.
I tried the memcpy solution, and it worked just fine, though it's a
lot of code to do a small thing, sleeping for a couple of ms.
It's not "a lot of work" for the computer. The memcpy() function is
highly optimized in the comm page, and unless you go out of your way
to disable it, a small memcpy like this will end up being inlined as a
number of load/store instructions, which is exactly what you'd get
from a structure assign or assigning a 64 bit value to another that
you weren't careful to align. The compiler really does know what it's
doing.
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).
Regards,
-- Terry
_______________________________________________
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