Re: ThreadSafe Note Scheduling Code (Was Re: Threading)
Re: ThreadSafe Note Scheduling Code (Was Re: Threading)
- Subject: Re: ThreadSafe Note Scheduling Code (Was Re: Threading)
- From: Bill Stewart <email@hidden>
- Date: Fri, 8 Aug 2003 15:45:28 -0700
On Friday, August 8, 2003, at 11:52 AM, Chris Rogers wrote:
Hi Robert,
Yes, the code Bill posted is only thread-safe with two threads
involved,
a queuing thread and a rendering thread. The thread safety breaks down
if you want to support multiple threads other than the render thread.
However, I think the code covers the 90% usage case, and I think it
would be
quite considerably more expensive to expect all MusicDevice AudioUnits
to
support multiple "secondary" threads, since this would requires thread
synchronization locks which in addition to being expensive could
block the render thread which would be really bad! I think at this
point,
the host would have to provide responsibility for the thread
synchronization,
and luckily I think this would rarely be necessary.
Actually, this wouldn't be alot of work...
You only have one render thread, so the only place left is the
potential to have 2 scheduling threads... Your wrapper class that is
dispatching to either queueing or immediate rendering. So, when you
realise that you have to go into the queued case, you could then lock
there so there is a fine lock taken in the wrapper around the queueing
of notes, and the read/write pointers protect the integrity of the
dequeueing from the render thread..
Bill
I think the code is completely thread safe for one single queuing
thread and one rendering thread, although it's always nice to have
people look at it to verify our assumptions...
Chris Rogers
Core Audio
Apple Computer
Maybe I'm missing something - but can somebody point out where the
thread safety comes in? What about the possibility that the AU is fed
MIDI data from multiple threads for example a MIDI Clock tick from
one MIDI source and MIDI notes from another?
And I agree with Urs that this queue should be always used which is
why I suggested a queue be part of the framework rather than
something to be added by each Music AU implementor.
Thanks,
Robert.
On Friday, August 8, 2003, at 04:46 AM, Urs Heckmann wrote:
Am Freitag, 08.08.03, um 03:41 Uhr (Europe/Berlin) schrieb Bill
Stewart:
In your Render call, you get the thread ID (pthread_self), of the
thread that you are being asked to render on.
In your API calls for starting and stopping notes you compare that
thread ID with the thread ID you are being called on to start/stop
a note, If it is the render thread, then you go through and do the
work immediately, if not, you queue a start/stop note
Thanks, this is fairly simple 8-)
But now I have another one:
- Imagine an intelligent host on a multiprocessor machine.
- It sees a bunch of Notes comming. Hence it takes its measures.
- It transfers the rendering from cpu A to cpu B, probably changing
thread ID of rendering, right?
- The Queue is called, still on cpu A, finds the right thread ID and
assumes safe immediate processing
- Some cycles thereafter rendering starts on cpu B, it alters the
thread ID, but too late...
- process interrupts queue, both work on same data -> leak, crash,
hanging note, whatever
Couldn't that happen?
Hence, shouldn't one always use the thread safe queue and never
assume safe to process immediately?
Cheers,
;) Urs
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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.