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
[EMAIL PROTECTED]
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
