Joel Sherrill wrote, on 19 Oct 2022: > > On 10/19/2022 3:12 AM, Geoff Clare via austin-group-l at The Open Group > wrote: > > I wrote, on 11 Oct 2022: > >> > >> I wrote, on 10 Oct 2022: > >>> > >>> I'm trying to understand the second sentence in this paragraph on the > >>> pthread_mutexattr_getprotocol() page: > >>> > >>> While a thread is holding a mutex which has been initialized > >>> with the PTHREAD_PRIO_INHERIT or PTHREAD_PRIO_PROTECT protocol > >>> attributes, it shall not be subject to being moved to the tail > >>> of the scheduling queue at its priority in the event that its > >>> original priority is changed, such as by a call to sched_setparam(). > >>> Likewise, when a thread unlocks a mutex that has been initialized > >>> with the PTHREAD_PRIO_INHERIT or PTHREAD_PRIO_PROTECT protocol > >>> attributes, it shall not be subject to being moved to the tail of > >>> the scheduling queue at its priority in the event that its original > >>> priority is changed.
[...] > When we implemented this long ago for RTEMS, we looked at that as > meaning that raising and lowering a thread's priority by inheritance > would not result in it going to the end of the FIFO for its original > priority level. If you do that, it ends up being the equivalent of a > yield as a side-effect of restoring a thread back to its original priority. > > A thread should be able to lock and unlock a priority ceiling mutex > without an implicit yield on the unlock. > > It's a lot of language that we had trouble parsing over two decades ago > to come to that conclusion. I will add that the Ada programming language > conformance tests check this behavior. I assume that means that this > is specified somewhere in that language standard. Any change in this > behavior will be noticed since Ada run-times based on POSIX threads rely > on this behavior. I really vaguely recall that we did implement it > initially with returning to the end of the priority FIFO, the test case > failed, and we tracked it down to needing to implement this behavior. > > I would hope it could be worded better but it is needed and depended upon. I agree that the behaviour you describe is what the standard should require (and almost certainly was intended to require). I will work on some wording changes and submit them in Mantis. -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
