I understand. I only use it to write to a command register, wait 50 us, and
then read a status register. I know that this kills lower priority
performance. What hurts even more is that this has to run at a very high
priority. But it’s happening is a device driver where waiting 500 us
(QNX4’s limit) would significantly reduce the performance of the device.
“Paul D. Smith” <pausmith@nortelnetworks.com> wrote in message
news:p5g01bi6rp.fsf@lemming.engeast.baynetworks.com…
%% “Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > writes:
bc> Actually I have my own time_n class that has a complete math
bc> library and sleep-like routines that also do something like
bc> nanospin(), all based on struct timespec.Note that nanospin() and nanosleep() are very different, and you
should be careful to use the one you need.nanosleep() releases the system to schedule another thread, because you
are saying that this thread doesn’t need the CPU any longer at the
moment. This thread will not be eligible to be scheduled again until
the sleep interval expires (or you’re woken up by a signal or
something).nanospin() does NOT release your hold on the CPU; it is a busy spin
that is specifically calibrated to take a precise amount of time, much
less (potentially) than a tick. No other thread will be scheduled while
you are waiting for the spin interval to complete (not withstanding
higher priority thread issues); this is essentially completely wasted
resources. You should generally only use this if you have pretty
stringent, hard real-time requirements.This is why it is not at all surprising (to me anyway >
> ) that
nanosleep() for less than a tick doesn’t reduce to a nanospin(); that
would be very inappropriate since they are really quite different
things.–
Paul D. Smith <> pausmith@nortelnetworks.com> > HASMAT–HA Software Mthds &
Tools
“Please remain calm…I may be mad, but I am a professional.” --Mad
Scientist
These are my opinions—Nortel Networks takes no responsibility for
them.