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: Herbie Robinson <email@hidden>
- Date: Wed, 20 Feb 2002 05:58:31 -0500
On Tuesday, February 19, 2002, at 03:04 , Andy Robinson wrote:
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.
on 2/19/02 9:44 AM, Doug Wyatt <email@hidden> wrote:
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.
Does the idea of turning interrupts off depend on a single-cpu situation?
Correct. Interrupt masking is not a reliable synchronization
mechanism on MP systems (because it only affects one CPU). For MP,
you need things like locks, message queues, semaphores, atomic list
threading, atomic counter incrementing, etc. Interrupt masking would
normally only be used in conjunction with locks to avoid deadlocks
with an interrupt handler.
Well, actually, there is one other way to use interrupt masking in an
MP situation: One can have per CPU data structures and mask to
protect the structures for the CPU one is running on. One must also
be wired to pull this off. I've been doing MP drivers for over 10
years and I've only used this trick once (it's a real PITA, you
really gotta have a serious performance need to go for this one).
In a multi-cpu environment does what Andy Robinson is wishing for translate
to "turn off interrupts and stop all the other CPUs?"?
But also I want to follow the interrupts-off-for-a-brief-time idea to its
logical conclusion. Combined with the time-constraint threads concept Andy
Robinson's wish suggests the following OS feature to me.
FEATURE:
Turn off all interrupts except the interrupts-off-for-too-long interrupt.
More specifically, the code-stream might look like:
turn MOST interrupts off with estimated maximum time
do some stuff, which might include looping
turn interrupts back on
The system would either approve or disapprove the maximum time, based on
established criteria, and would generate a trapable exception if the time is
unacceptable.
Meanwhile if the time limit is exceeded a different trapable exception is
generated. So the net result is that there is no mystery as to whether the
approach succeeded or not. Faster computers would not be a problem, but
slower computers might not be supported. If the exception is generated a
"computer too slow" warning could be given to the user. (Thanks!)
This assumes that things like basic memory access have some deterministic
maximim limits, and maybe that is a problem.
The above idea might work much better in a non-looped environment, in which
the code might look like:
turn off ALL interrupts until forward label "x" is reached
do some stuff with no jump instructions allowed
x: turn interrupts back on
This is more of a hardware suggestion, and so perhaps off-topic, but it
seems to me the lack of control over what is "atomic" in a given piece of
hardware would strongly suggest that hardware support for something like the
above would be desirable. The label "x" would be allowed to be only a
certain number of instructions forward. This would permit the OS to have
some flexibility over what is considered "atomic". Unfortunately I guess
this would also mean putting a lock on the bus, and maybe that is not
doable.
Thanks,
Kurt Bigler
Masking all CPUs is an extremely inefficient operation on an MP
system. The interrupt masks are generally in the CPU chips
themselves and can only be changed by the CPU they apply to (This is
true for 68k, i860, IA32, PA-RISC and IA64 -- don't know about PPC,
but odds are against it). That means that the only way to do It
requires sending the highest priority interrupt to all the other
CPUs. At that point, the other CPUs take the interrupt, must spin on
a flag and can't return from the interrupt until the flag says they
can -- They can't arbitrarily continue execution because they could
be in an infinite loop in user mode code and you would never hear
from them again. It's actually harder than that, because there will
be race conditions getting all the CPUs interrupted and safely
masked, too.
The kind of protection mechanisms one wants are the kind that don't
interfere with what the other CPU is doing, because 99% of the time
it will be totally unrelated (one just doesn't want to die in flames
the other 1% of the time). That's where we get into the CPUs having
special instructions for doing various atomic memory operations. In
20 year old designs, atomic memory operations did involve locking the
hardware bus by one CPU so it could do multiple bus cycles without
interference. The trend in most designs today is to define simple
atomic operations that are actually executed by the memory
controllers to avoid locking the bus. The atomic operations are
usually of the type "If the location X contains Y, replace it with Z
and tell me if you did it." What's really scary, is that most
processors are now capable of executing those instructions in the
caches (in fact, on the IA64, the memory locations MUST be cached to
use those instructions!). At any rate, that primitive can be used to
implement locks, semaphores, atomic counters and some single threaded
queues (I haven't had time to look at the atomic threading routines
referred to earlier to see what is possible...).
--
-*****************************************
**
http://www.curbside-recording.com/ **
******************************************
_______________________________________________
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.