Re: pthread_cond_signal and priority inversion
Re: pthread_cond_signal and priority inversion
- Subject: Re: pthread_cond_signal and priority inversion
- From: Brian Willoughby <email@hidden>
- Date: Mon, 23 May 2016 20:30:58 -0700
I could be wrong, but it seems safe if the signal or semaphore only holds the lock long enough to update a small, finite amount of memory. I assume that the lock is taken right before writing to a 32-bit value (64-bit at most) and then unlocked right away. I don't see how that could block for very long. Of course, a look at the mach source is required to make sure something worse isn't happening. In other words, I doubt that memory is being allocated while the lock is held, because the signal or semaphore should have already been allocated before the lock is taken.
Caveat: I haven't looked into these details in quite a while.
Brian Willoughby
On May 23, 2016, at 7:20 PM, Michael Tyson <email@hidden> wrote:
> 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?
_______________________________________________
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