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

[Jan Kiszka <jan.kiszka@domain.hid>]

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

Gilles Chanteperdrix wrote:
> Bill Gatliff wrote:
>> Guys:
>>
>> Philippe Gerum wrote:
>>
>>> 	[posix]
>>> 	* Fix pthread_cond_wait() upon signal receipt (grab mutex anew).
>>>  
>>
>> 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.
> 
> 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.

The problem with stock kernel is the FUTEX_WAIT operation: That one is
used by glibc to block on non-PI mutexes. It dequeues in FIFO order,
regardless of the waiter's priority. FUTEX_LOCK_PI (used e.g. for
PTHREAD_PRIO_INHERIT mutexes since glibc 2.5) is fine again.

The -rt patch contains a fix for FUTEX_WAIT, and I think I saw some
mainline patch once circulating as well. But it received a bit
scepticism due to possible performance regression for futex users that
don't care about priorities. And so nothing happened yet (I just checked
latest git)...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]