Re: scheduling a block from a render callback
Re: scheduling a block from a render callback
- Subject: Re: scheduling a block from a render callback
- From: Kyle Sluder <email@hidden>
- Date: Tue, 14 Jan 2014 08:12:40 -0800
On Tue, Jan 14, 2014, at 06:06 AM, Paul Davis wrote:
> On Mon, Jan 13, 2014 at 9:39 PM, Doug Wyatt <email@hidden> wrote:
>
> > Some techniques that can be used safely from a realtime thread include:
> >
> > - signal a pthread condvar (but don't lock the associated mutex. this is
> > useful if you signal from the realtime thread continuously while you
> > continue to see the condition under which you want to wake the
> > lower-priority thread.)
> >
>
> I'd like to stress the continuously part of Doug's response here. If you
> do
> not do it continuously (and even if you do), then this method is subject
> to
> race conditions and in the worst case scenario (one involving developers
> who don't know enough about what they are doing), priority inversion.
> details here:
> https://groups.google.com/forum/?hl=ky#!msg/comp.programming.threads/wEUgPq541v8/ZByyyS8acqMJ
>
> Used carefully, though (where carefully means "correctly definining and
> understanding the relationship between the low priority ToBeWoken thread
> and the realtime thread(s)"), then this is a useful technique.
Given how frequently this comes up, I'm starting to wonder if there
shouldn't be API for this. Something like
AudioUnitPostNotificationAsync(uint32_t notification) and
AudioUnitAddNotificationHandler(dispatch_queue_t queue, void
(^handler)(AudioUnit unit)). Internally, AudioUnit would take care of
shunting waking a non-realtime thread that actually did the work of
dispatching the registered handlers to each queue.
--Kyle Sluder
_______________________________________________
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