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: Sun, 17 Feb 2002 13:06:29 +0000
Thanks for the replies on this. Here's my attempt to understand what I'm
being told.
That the callbacks passed to SndNewChannel & MIDIInputPortCreate do run
in pre-emptively scheduled (not "cooperative") threads separate from the
main app thread, so the callback can interrupt the app at any time and
vice-versa.
That I should therefore protect the critical bits of queue manipulation
with a mutex or semaphore, but on the other hand I'm told not to set a
lock in a callback - isn't a mutex a lock? If I don't set a lock in the
callback, how can I prevent the main app from interrupting it at a
critical moment and fiddling with the queue?
If wrap a mutex around the critical queue manipulation in both app code
and callback code then I need to be certain they really are separate
pre-emptively scheduled threads. For instance, if I had done this under
Classic Mac then I think it would have been disastrous - if the app
claims the mutex, then is interrupted by the callback which is then
unable to claim the mutex and blocks, then we would have been totally
dead, yes? Can I be sure that under OS-X if this happens, the app thread
would continue to run and release the mutex?
I'm also told that
>
code on an MP machine, one is not that lucky). The thread context on
>
OS X is also much more robust than the interrupt context: It can
>
block.
... so are the callbacks in "thread context" or "interrupt context"? I'd
be grateful if someone can tell me.
file:///Developer/Documentation/Essentials/SystemOverview/
InverEnvironissues/Threading_Packages.html
is useful.
It seems I could use either of 2 approaches :
- Multiprocessing Services (MPCreateCriticalRegion)
As documented by Apple. I hadn't previously been clear whether MP
services are appropriate when the machine isn't MP but it seems I'm
being told they are.
- pthreads (POSIX) (pthread_mutex_lock)
http://lists.apple.com/mhonarc/darwin-development/msg11516.html
The tru64 links on this page got me "cannot find server" but I'll try
again, or do a bit of searching (have they moved?).
What I'm not clear about is, do these 2 threading approaches map onto
identical mechanisms in Mach? What I mean is, if the callback thread has
been created - somewhere in some driver or bit of kernel or something -
by using pthreads then does it matter if I then lock it using MP
services API, or vice versa?
Clarification will be most welcome, thank you.
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.