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: Andy Robinson <email@hidden>
- Date: Tue, 19 Feb 2002 11:04:55 +0000
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?
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.
A long time ago I had a bad experience - intermittent crashing - which
eventually turned out to be caused by reading - just reading - (in main
app code) an integer variable which was being incremented by an
interrupt handler. The problem went away when I briefly disabled
interrupts while reading the value. This has made me very wary about
accessing a shared variable from threads/interrupts that may interrupt
each other, but perhaps I'm over-cautious.
The FIFO approach that's been mentioned by a couple of people, I take it
what we're saying is I put messages or whatever in a circular buffer
whose size is a pwr of 2 (256 let's say) and I have 2 volatile integer
variables shared between main thread and callback.
const int BUFSIZ = 256;
const int BUFMASK = BUFSIZ - 1;
volatile int read_point = 0, write_point = 0;
In the callback, putting a message in the buffer, I go
if ( ((write_point + 1) & BUFMASK) == (read_point & BUFMASK) )
//...then writing another would cause wrap-around, we're
// full and must throw this one away
return;
buf[write_point & BUFMASK] = message data;
++write_point;
Then in the main app, I go
if ( (write_point & BUFMASK) == (read_point & BUFMASK) )
return; // empty
message data = buf[read_point & BUFMASK]; // we have msg
++read_point;
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.
Andy Robinson, Seventh String Software, www.seventhstring.demon.co.uk
_______________________________________________
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.