title: POSIX mutex protocol - what exactly does this spec mean?
body: <p>In this documentation of POSIX mutex protocols - <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_getprotocol.html#" rel="nofollow">http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_getprotocol.html#</a> - we can read following section:</p>
  
  <blockquote>
    <p>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.</p>
  </blockquote>
  
  <p>This probably is a reference to this fragment:</p>
  
  <blockquote>
    <p>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.</p>
  </blockquote>
  
  <p>(source - <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_08" rel="nofollow">http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_08</a> , SCHED_FIFO description)</p>
  
  <p>English is not my first language, so I'm having hard time understanding what exactly does it say...</p>
  
  <p>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?</p>
  
  <p>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.</p>
  
  <p>Any ideas?</p>