any fairness in NTPL pthread mutexes?

any fairness in NTPL pthread mutexes?

[Christopher Friesen]

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

Re: any fairness in NTPL pthread mutexes?

[Lee Revell]

On Mon, 2005-10-31 at 11:57 -0600, 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.)?

I believe it's currently FIFO in violation of POSIX which specifies
priority based wakeup.  AIUI one of the main goals of the realtime &
robust mutexes work is to fix this.

Lee

Re: any fairness in NTPL pthread mutexes?

[Lee Revell]

On Mon, 2005-10-31 at 13:06 -0500, Lee Revell wrote:
> On Mon, 2005-10-31 at 11:57 -0600, 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.)?
> 
> I believe it's currently FIFO in violation of POSIX which specifies
> priority based wakeup.  AIUI one of the main goals of the realtime &
> robust mutexes work is to fix this.

Sorry this is wrong - the current behavior is allowed by POSIX for
SCHED_OTHER but not SCHED_FIFO or _RR.

Lee

Re: any fairness in NTPL pthread mutexes?

[Joe Seigh]

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.)?
> 

SCHED_OTHER.

If there are any waiting tasks when the mutex is unlocked, one of the waiting
tasks is woken up but not given lock ownership.  It has to acquire the mutex
on its own.  If it fails because another thread got the mutex first, then it
goes back to waiting.   It's sometimes called an adaptive mutex.  It's a little
faster than a FIFO mutex.  It recovers from intermittent contention better.
With heavier contention, some threads in theory could starve, something that
wouldn't happen with a FIFO mutex.

--
Joe Seigh

Re: any fairness in NTPL pthread mutexes?

[James Courtier-Dutton]

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.

James

Re: any fairness in NTPL pthread mutexes?

[Lee Revell]

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

Re: any fairness in NTPL pthread mutexes?

[Robert Hancock]

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.)?
> 

Not in the pthread spec (at least not for normal SCHED_OTHER tasks), and 
Linux/glibc don't really provide any either. In particular, if one 
thread unlocks a mutex and immediately tries to relock, there is no 
guarantee that any other thread waiting on the mutex will be able to get 
in and lock it before the first thread can relock.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/