Re: Sound Manager & MIDI callbacks, interrupts and threads
Re: Sound Manager & MIDI callbacks, interrupts and threads
- Subject: Re: Sound Manager & MIDI callbacks, interrupts and threads
- From: Doug Wyatt <email@hidden>
- Date: Tue, 19 Feb 2002 09:44:36 -0800
On Tuesday, February 19, 2002, at 03:04 , Andy Robinson wrote:
Thanks again for more replies.
I'm being warned of the dangers of the main app thread holding the lock
for too long, but in fact I only hold the lock for long enough to do a
tiny bit of arithmetic - increment a pointer, decrement a count, that
sort of thing - so ... er ...
As I write this I realise maybe that's not good. The OS might decide to
give some other app a big slice of time right at the moment my app's
main thread is holding the lock. Do I need to worry about this?
Not excessively. In theory what should happen is:
- Main thread takes lock.
- If a high-priority callback arrives and tries to take the lock, it
fails and blocks (is made ineligible to run). The scheduler then
schedules the highest-priority thread that is eligible to run, applying
round-robin or other logic if there are multiple threads at the same
priority. Normally this will be your main thread; if you're only
protecting a tiny section of code, there's only a small chance that some
other thread will get made eligible to run in that execution slice
(though large enough a chance that you must be prepared for it). But
this is just the normal workings of a pre-emptive multi-tasking OS.
- Main thread finishes work, releases lock. Any threads that were
blocked on the lock are now made eligible to run. If one of them has a
higher priority than your main thread (e.g. the callback), it should
then get scheduled to run.
It seems a great pity we can't just disable interrupts briefly, life
would be so much simpler. An instruction to "disable interrupts for the
next 20 instructions" would do the job without endangering the stability
of the OS, it seems to me.
But you never really know how many instructions your critical region
is. It might be 12 instructions today, 24 instructions if you flip a
compiler setting.
The history of the OS is so rife with examples where someone thought
their critical regions were tiny, but they'd end up turning off
interrupts for milliseconds at a time, completely disastrous. From the
OS's point of view, giving an app the ability to turn off interrupts is
to give it the ability to completely lock up the machine (what if it has
a bug so that sometimes it doesn't re-enable interrupts?). With today's
standards of reliability, that's unacceptable.
This probably contains bugs as I'm writing it off the top of my head,
but is the concept safe? Someone said that it's hard to know whether an
operation is "atomic" - something about single bus transactions.
Have a look in CoreServices/DriverSynchronization.h -- there are
functions in there that manipulate memory in truly atomic ways.
Doug
--
Doug Wyatt
work: email@hidden (CoreAudio)
personal: email@hidden
http://www.sonosphere.com
"Changing OS's is the corporate equivalent of molting -- you're very
vulnerable after you've done it but you have to do it to survive".
-- Ray Spears
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.