Per this discussion http://stackoverflow.com/a/4544494/571778 and more detailed info 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]> 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]> > 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/kevin.c.dixon%40gmail.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]
