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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
