Re: AU Threading Question
Re: AU Threading Question
- Subject: Re: AU Threading Question
- From: Brian Willoughby <email@hidden>
- Date: Fri, 08 Apr 2011 03:27:59 -0700
You may be right; only Stephen can say what he was asking.
However, he mentioned "a plain C float array" that "is a member of
the AU class itself." AudioUnits are implemented in C++ and thus
object members should not be subject to Objective C @synchronized
(self) constructs unless I'm missing some newfangled trick.
As for "something akin to" @synchronized(self), I think Render would
be broken if it blocked this way for everyone without being
documented in the API. Render threads pretty much must always be
time constrained unless you're doing an offline render (a process
which happens to be incompletely documented, as we know ;-) but I
digress).
In addition, it would be *really bad design* for a function to put a
mutex around the entire collection of instance data instead of around
individual data collections within the instance data. At most there
would be a mutex around access to any part of the float array, at the
other end of the spectrum there would be no protection at all.
Brian Willoughby
Sound Consulting
On Apr 8, 2011, at 03:06, tahome izwah wrote:
Brian, I think what he's asking is if either the thread making the
Render call or GetProperty does something akin to @synchronized(self),
which would prevent its data structures from being updated while the
call is underway (creating a lock in the process). On a time
constrained render thread this could pose a problem.
I think that they're not mutually exclusive in their access to the
instance data, but maybe someone from the CA team can confirm this.
2011/4/8 Brian Willoughby <email@hidden>:
I don't understand your question at all, but perhaps there is a
misunderstanding of the difference between what it means for two
threads to
access the same data versus what it means for a thread to call a
blocking
function or enter a mutex condition.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden