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: Kurt Bigler <email@hidden>
- Date: Tue, 19 Feb 2002 20:13:22 -0800
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?
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
_______________________________________________
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.