[Xenomai-core] Re: [Xenomai-help] Xenomai v2.3.1

[Bill Gatliff <bgat@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1750 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 2344 bytes --]