There's a debate on the Linux kernel mailing list right now about the
interpretation of a section in the SuS definition of 'pthread_mutex_unlock'.
SuS says:

"If there are threads blocked on the mutex object referenced by mutex when
pthread_mutex_unlock() is called, resulting in the mutex becoming available,
the scheduling policy shall determine which thread shall acquire the mutex."

    This is being interpreted to prohibit the releasing thread from
reacquiring the mutex. The idea is that if there are waiting threads, the
releasing thread cannot be one of them. Since the the scheduling policy
*shall* determine which thread *shall* acquire the mutex *when*
pthread_mutex_unlock is called, then it can't choose the current thread,
because it can't know that the current thread wants the mutex back by then.

    Is there any way to refute this interpretation? Unfortunately, it sounds
reasonable (though, I hope, not intended!).

    My response is simply that it does not say the scheduling policy shall
determine which thread shall acquire the mutex when pthread_mutex_unlock is
called. For example, if I say, "if there are two people who want to request
use of my car on Monday, I shall decide who gets it". That does *not* mean
I'll decide on Monday. It means if the people request on Monday, I'll decide
at some unspecified future time. But that seems kind of weak.

    DS