[Xenomai-core] Re: [Xenomai-help] Xenomai v2.3.1
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-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [Xenomai-help] Xenomai v2.3.1
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-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [Xenomai-help] Xenomai v2.3.1
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. Xenomai POSIX skin implements this correctly as well. To be more specific about this, Xenomai mutexes, like mutexes of all other skins, are built using the "xnsynch_t" objects [2] which has two possible ways of implementing its internal wait queue: either in FIFO order if xnsynch_init is passed the XNSYNCH_FIFO flag, or in priority order if xnsynch_init is passed the XNSYNCH_PRIO flag. pthread_mutex_init passes the XNSYNCH_PRIO flag to xnsynch_init. [1]:http://www.opengroup.org/onlinepubs/95399/functions/pthread_mutex_lock.html [2]:http://www.xenomai.org/documentation/trunk/html/api/group__synch.html -- Gilles Chanteperdrix ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [Xenomai-help] Xenomai v2.3.1
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. :) Thanks, b.g. -- Bill Gatliff [EMAIL PROTECTED] ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
