Bill Gatliff wrote:
> 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...
Yet another possibility is that the pthreads that are believed to run in
SCHED_FIFO or SCHED_RR policy are not really running with one of these
policies. There is (or was, maybe it was fixed) a bug in the glibc:
setting scheduling parameters with pthread_attr_setsched* does not work.
Don't laugh, try it an call pthread_getschedparam from the created thread.
--
Gilles Chanteperdrix
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
