From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <460013C8.3050003@domain.hid> Date: Tue, 20 Mar 2007 12:03:04 -0500 From: Bill Gatliff MIME-Version: 1.0 References: <1174379951.5068.5.camel@domain.hid> <46000AFE.9070504@domain.hid> <4600125A.6000304@domain.hid> In-Reply-To: <4600125A.6000304@domain.hid> Content-Type: multipart/alternative; boundary="------------080905010507000103040203" Subject: [Xenomai-core] Re: [Xenomai-help] Xenomai v2.3.1 List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai@xenomai.org, xenomai@xenomai.org This is a multi-part message in MIME format. --------------080905010507000103040203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------080905010507000103040203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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

--------------080905010507000103040203--