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
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
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
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
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 [email protected]
Home Page: http://www.roberthancock.com/
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
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