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]> 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 - search for > _dispatch_semaphore_signal_slow, you’ll see semaphore_signal) > - Mach semaphores (semaphore_signal) use a lock (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 - > search _pthread_cond_signal) - _pthread_cond_signal calls __psynch_cvsignal > 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 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 > > Loopy: Record, loop, layer. Like a pro. > http://loopyapp.com > > On 24 May 2016, at 09:19, Ross Bencina <[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/ > > (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]) > Help/Unsubscribe/Update your Subscription: > > https://lists.apple.com/mailman/options/coreaudio-api/michael%40atastypixel.com > > This email sent to [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/paul%40linuxaudiosystems.com > > This email sent to [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/archive%40mail-archive.com This email sent to [email protected]
