Gilles Chanteperdrix wrote:

Probably OT, but someone was complaining to me the other day that 
pthreads running on SCHED_FIFO/SCHED_RR that are blocked on mutexes 
don't release in priority order.  This was on a stock 2.6.18 kernel, 
"recent glibc" (I didn't catch which version or config), ARM9 platform.

First question: Is this actually true?

Second question: Does Xenomai fix this?  Do more recent kernel 
developments fix this?

Point me at the appropriate RTFM or code if that's the appropriate 
answer.  :)


The appropriate RTFM is the POSIX spec [1]

In short, it 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."

So, the correct implementation is to release a mutex in priority order.

Right, I'm fully aware of that (I teach a class on POSIX.1b from time to time).

But this person insisted that things didn't work that way in a stock 2.6.18--- which was a complete surprise to me. Just wondering if anyone here had noticed or not.

I suppose another possibility is that the "mutex" they were referring to was a kernel mutex used to implement blocking i/o in a driver, and not a userspace POSIX mutex. But I would expect that one to behave itself too...

I think the glibc implements this correctly (at least NPTL), on the
other hand, I believe it is not true for threads running with the
SCHED_OTHER policy, in order to prevent starvation.

Right. All bets are off with SCHED_OTHER, which is the way things are supposed to be.

b.g.

-- 
Bill Gatliff
bgat@domain.hid