In this documentation of POSIX mutex protocols - http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_getprotocol.html# - we can read following section:
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.
This probably is a reference to this fragment:
If a thread whose policy or priority has been modified other than by pthread_setschedprio() is a running thread or is runnable, it then becomes the tail of the thread list for its new priority.
(source - http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_08 , SCHED_FIFO description)
English is not my first language, so I'm having hard time understanding what exactly does it say...
Does it mean that when thread's priority is boosted (due to inheritance or ceiling protocol) it is not placed at the tail of the new priority, but at the head? Or maybe this describes the situation of priority change due to a call to sched_setparam() (or similar function) by this thread itself or by another thread? Maybe it is just a strange description of the fact, that such thread executes at the priority inherited from the mutex, so no changes to it's original priority make any difference?
I tried searching for a different description of this behavior, but all specs are just copies of the original, some of them use slightly different words, but this makes no difference at all.
Any ideas?
The text is not wonderfully easy to untangle...
...but I agree with you, there is the general rule that changes to policy/priority for a thread cause it to be put to the back of the relevant priority queue, except where that change is made by
pthread_setschedprio()......and then there are the exceptions to that rule.
...so, while a pthread is holding a mutex and its priority is changed to avoid priority inversion, then it seems reasonable for the thread to not be moved to the back of its priority queue.
...not so obvious, is what this means:
...I think the key here is the word "original". I think this means that if the thread's real priority has been changed (explicitly by some scheduling function) but the thread has continued running, then a later mutex unlock is not required to worry about it. I think this is for efficiency... the mutex code has to worry about its own priority issues, but not any others.