Great! I’ve also had word from the Core Audio team that Mach semaphores are very likely provably safe; the internal implementation apparently disables thread preemption around the critical regions.
> On 21 Jun 2016, at 03:45, Kevin Dixon <[email protected]> wrote: > > Per this discussion > http://stackoverflow.com/a/4544494/571778 > <http://stackoverflow.com/a/4544494/571778> > and more detailed info > https://groups.google.com/forum/?hl=ky#!msg/comp.programming.threads/wEUgPq541v8/ZByyyS8acqMJ > > <https://groups.google.com/forum/?hl=ky#!msg/comp.programming.threads/wEUgPq541v8/ZByyyS8acqMJ> > > We see that use of pthread_cond_signal does not require obtaining the > associated mutex, so I would more or less assume that pthread_cond_signal is > non-blocking by itself. If you only have 1 thread waiting on this, then it is > totally fine. > > Kevin > > On Tue, May 24, 2016 at 6:21 AM, Paul Davis <[email protected] > <mailto:[email protected]>> wrote: > Basically, if you want inter-thread explicit communication then unless you > are able to use 100% wait-free data structures, there is no way to avoid a > lock *somewhere*. And using 100% wait-free data structures is more or less > impossible for systems of any notable complexity, and this is specifically > true of any general purpose OS kernel (such as mach) where the tradeoffs > required to do everything wait-free generally argue against it. > > So, you're not going to be able to avoid locks showing up in the code path. > You're working on a general purpose OS - even if OS X has reasonable RT-like > capabilities, it isn't an RTOS. > > The only way you can avoid the ones in use space is to avoid the explicit > communication represented by any signalling mechanism (semaphores, > pthread_cond_t and the like). You have to make sure that the non-RT thread(s) > simply wake up enough to ensure that whatever communication is required for > the RT thread(s) to continue to function is guaranteed to happen. That is, > the non-RT threads wake on a timer, check for any requests/data/whatever from > the RT threads (in a lock-free FIFO), and deal with it. This can be done with > no user-space locking at all. > > Having said that, I can tell you that I rejected this design within Ardour in > favor of taking the risk of invoking a lock from user space. We generally use > POSIX FIFOs, and we write a single byte to the write side of the FIFO from > the RT thread in order to wake up the non-RT thread(s). There is no explicit > lock in our code, but this does traverse the kernel filesystem code, which > implies some locking takes place. How much locking depends on what kernel is > involved, and the answer is pretty different on OS X, Linux and Windows (we > support all three with the same code). > > I'm not sure that our rejection of the wait-free approach was correct, but it > does avoid having the non-RT thread waking over and over and over and over > just to check if anything needs to be done, rather than waking only when work > is actually required. > > > > On Mon, May 23, 2016 at 10:20 PM, Michael Tyson <[email protected] > <mailto:[email protected]>> wrote: > Bugger. Yep. You’re both absolutely right. And sure enough, neither dispatch > semaphores nor mach semaphores, nor condition variables are safe. All use > locks of one form or another. > > For the record: > > - Dispatch semaphores (dispatch_semaphore_signal) are actually built upon > mach semaphores (https://goo.gl/6nbU9C <https://goo.gl/6nbU9C> - search for > _dispatch_semaphore_signal_slow, you’ll see semaphore_signal) > - Mach semaphores (semaphore_signal) use a lock (https://goo.gl/enxiiT > <https://goo.gl/enxiiT> - search for semaphore_signal_internal) - > specifically, semaphore_signal calls semaphore_lock calls wait_queue_lock > which has a platform-dependent implementation; a spin lock on i386 (no source > available for arm). > - pthread_cond_signal also uses a lock (https://goo.gl/wpFz1k > <https://goo.gl/wpFz1k> - search _pthread_cond_signal) - _pthread_cond_signal > calls __psynch_cvsignal https://goo.gl/nCx6LC <https://goo.gl/nCx6LC> calls > ksyn_wqlock calls lck_mtx_lock which is in xnu/osfmk and has a > platform-dependent implementation, no arm source. For broadcast signalling: > rather than __psynch_cvsignal, __psynch_cvbroad is called, but there the > trail goes cold - it appears to be a system call. Closest I could find was > _psynch_cvbroad at https://goo.gl/nCx6LC <https://goo.gl/nCx6LC> which calls > __psynch_cvsignal again. > > I guess either the folks that made CAGuard/AUAudioFilePlayer don’t know or > don’t care, or know something I don’t about it being okay to use locks on the > realtime thread =) > > Would love a comment from someone in Core Audio. > > Anyway - any other thoughts, before I convert my code back to using main > thread polling? Am I being too precious about this? Have I been wrong the > whole time, and locks are actually fine in this context? > > -- > Michael Tyson | atastypixel.com <http://atastypixel.com/> > > Loopy: Record, loop, layer. Like a pro. > http://loopyapp.com <http://loopyapp.com/> >> On 24 May 2016, at 09:19, Ross Bencina <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 24/05/2016 1:37 AM, Paul Davis wrote: >>> Unless you know the author of an email works inside Apple in a highly >>> technical role, I would advise against staking too much faith in a >>> comment like "or better yet dispatch semaphores". And someone who >>> doesn't know what POSIX semaphores are is doubly unlikely to be the >>> right person to take advice from on this matter. >> >> I have a similar feeling. I'd go further and suggest that even if a highly >> knowledgeable person said something in the past, it should not be taken as a >> binding contract that OS X will continue to behave in a certain way. >> >> @Michael Tyson: As far as I know, all of the relevant layers are open-source >> (pthreads, libdispatch, kernel). It's worth taking at least a cursory glance >> at the source code for the functions that you're interested in. >> >> http://opensource.apple.com/ <http://opensource.apple.com/> >> >> (For a while, pthreads source code was omitted. I haven't checked lately, >> you may have to look at older releases to find it.) >> >> Cheers, >> >> Ross. >> _______________________________________________ >> 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/michael%40atastypixel.com >> >> <https://lists.apple.com/mailman/options/coreaudio-api/michael%40atastypixel.com> >> >> This email sent to [email protected] <mailto:[email protected]> > > _______________________________________________ > 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/paul%40linuxaudiosystems.com > > <https://lists.apple.com/mailman/options/coreaudio-api/paul%40linuxaudiosystems.com> > > This email sent to [email protected] > <mailto:[email protected]> > > > _______________________________________________ > 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/kevin.c.dixon%40gmail.com > > <https://lists.apple.com/mailman/options/coreaudio-api/kevin.c.dixon%40gmail.com> > > This email sent to [email protected] <mailto:[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]
