Subject: Re: any fairness in NTPL pthread mutexes?
From: Lee Revell <rlrevell@joe-job.com>
To: James Courtier-Dutton <James@superbug.co.uk>
Cc: Christopher Friesen <cfriesen@nortel.com>, linux-kernel@vger.kernel.org
In-Reply-To: <4368FBA6.5040604@superbug.co.uk>
References: <43665B08.6040005@nortel.com>  <4368FBA6.5040604@superbug.co.uk>
Content-Type: text/plain
Date: Wed, 02 Nov 2005 13:47:54 -0500
Message-Id: <1130957274.9163.1.camel@mindpipe>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1285
Lines: 35

On Wed, 2005-11-02 at 17:47 +0000, James Courtier-Dutton wrote:
> Christopher Friesen wrote:
> > 
> > I'm using NPTL.
> > 
> > If I have a pthread mutex currently owned by a task, and two other tasks 
> > try to lock it, when the mutex is unlocked, are there any rules about 
> > the order in which the waiting tasks get the mutex (ie priority, FIFO, 
> > etc.)?
> > 
> > Thanks,
> > 
> > Chris
> > -
> 
> There is no fairness at all. It's currently not designed to be fair 
> either. The reasons for this I can't remember, but there was talk at the 
> KS about it and I just remember the answer. I think it had something to 
> do with "If we implement fairness, general locking performance will drop 
> and we prefer performance over fairness."
> 
> The solution is to modify your program so as not to rely on fairness.

Or try RT-NPTL + realtime and robust mutexes kernel patches.  The
problem and solution is described in more detail here:

http://developer.osdl.org/dev/robustmutexes/src/fusyn.hg/Documentation/fusyn/fusyn-why.txt

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/