• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: pthread_cond_signal and priority inversion
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pthread_cond_signal and priority inversion

  • Subject: Re: pthread_cond_signal and priority inversion
  • From: Kevin Dixon <email@hidden>
  • Date: Mon, 20 Jun 2016 10:45:21 -0700
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@hidden> 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@hidden> 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
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


 _______________________________________________
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

 _______________________________________________
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
  • Prev by Date: Re: AVAssetReader how to get file size
  • Next by Date: Determining the maximum number of channels in use for a device
  • Previous by thread: Audio Unit Extension using an audio graph
  • Next by thread: Determining the maximum number of channels in use for a device
  • Index(es):
    • Date
    • Thread