> Of course the shorter the critical section, the less likely priority > inversion will ever happen.
I guess that’s where it comes down to risk/reward - I’m pretty risk-adverse, though! > @Michael, I guess you need to also consider whether lock contention is > actually possible. A spinlock on a never-contended lock would be safe for > example. True - alas, it is an issue with mach semaphores, at least. It’s locked on every wait, so there’s a reasonably high contention chance. The pthread condition source is a tad convoluted for me to determine this in my current mental state, though =) > On 24 May 2016, at 18:24, Ross Bencina <[email protected]> wrote: > >> I don't see how that could block for very long. > > The number of instructions in the critical section is not relevant if the > thread holding the lock gets pre-empted. That's the definition of priority > inversion. > > Of course the shorter the critical section, the less likely priority > inversion will ever happen. > > @Michael, I guess you need to also consider whether lock contention is > actually possible. A spinlock on a never-contended lock would be safe for > example. > > 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]
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]
