Many thanks, Kyle, that’s most helpful! Some further digging: it looks like not only are condition variables and mach semaphores acceptable, but dispatch semaphores are too, and are apparently even preferable (http://lists.apple.com/archives/darwin-dev/2012/Oct/msg00004.html).
So, all great news! -- Michael Tyson | atastypixel.com Loopy: Record, loop, layer. Like a pro. http://loopyapp.com > On 20 May 2016, at 08:41, Kyle Neideck <[email protected]> wrote: > > You might find this thread useful if you haven't seen it already: > https://lists.apple.com/archives/coreaudio-api/2010/Oct/msg00245.html > <https://lists.apple.com/archives/coreaudio-api/2010/Oct/msg00245.html> > (continues at > https://lists.apple.com/archives/coreaudio-api/2010/Oct/msg00252.html > <https://lists.apple.com/archives/coreaudio-api/2010/Oct/msg00252.html>). > > I also found this post where Jeff Moore says that pthread_cond_signal is OK: > https://lists.apple.com/archives/coreaudio-api/2009/Nov/msg00174.html > <https://lists.apple.com/archives/coreaudio-api/2009/Nov/msg00174.html>. In > this 2006 post he says that there "is a spin lock in the pthread > implementation" (though I'm not completely sure that includes > pthread_cond_signal) but that it very rarely causes problems: > https://lists.apple.com/archives/coreaudio-api/2006/Jan/msg00044.html > <https://lists.apple.com/archives/coreaudio-api/2006/Jan/msg00044.html>. I've > been using Mach semaphores, which are also fine according to that post. > > Kyle > > > On 19 May 2016 at 19:55, Michael Tyson <[email protected] > <mailto:[email protected]>> wrote: > Hi folks, > > I noticed recently that the AUAudioFilePlayer audio unit is using > pthread_cond_signal from its render function, via CAGuard::Notify > (http://goo.gl/VErpxz <http://goo.gl/VErpxz>), itself a piece of code made > available to the public as part of the Core Audio Utility Classes > (https://goo.gl/RFMxcL > <https://developer.apple.com/library/ios/samplecode/CoreAudioUtilityClasses/Listings/CoreAudio_PublicUtility_CAGuard_cpp.html>). > > I always thought pthread_cond_signal was a no-no for use on the audio thread > due to the risk of priority inversion; this post from way back in 2002 > reports that pthread_cond_signal can block http://goo.gl/DwFYUq > <http://goo.gl/DwFYUq>, although I’ve not followed up on the findings. > > Consequently, I’ve always used polling, rather than a condition variable or > semaphore, but this can cause a bit of lag, or an awkward amount of CPU > consumption. > > Is the presence of pthread_cond_signal in CAGuard and AUAudioFilePlayer an > indication that this is now safe? > > Many thanks, > Michael > > -- > Michael Tyson | atastypixel.com <http://atastypixel.com/> > > Loopy: Record, loop, layer. Like a pro. > http://loopyapp.com <http://loopyapp.com/> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Coreaudio-api mailing list ([email protected] > <mailto:[email protected]>) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/coreaudio-api/spam%2Bcoreaudiolist%40bearisdriving.com > > <https://lists.apple.com/mailman/options/coreaudio-api/spam%2Bcoreaudiolist%40bearisdriving.com> > > This email sent to [email protected] > <mailto:spam%[email protected]> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Coreaudio-api mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/coreaudio-api/michael%40atastypixel.com > > This email sent to [email protected]
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
