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
Subject: Re: any fairness in NTPL pthread mutexes?
Date: Wed, 02 Nov 2005 13:47:54 -0500 [thread overview]
Message-ID: <1130957274.9163.1.camel@mindpipe> (raw)
In-Reply-To: <4368FBA6.5040604@superbug.co.uk>
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
next prev parent reply other threads:[~2005-11-02 18:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-31 17:57 any fairness in NTPL pthread mutexes? Christopher Friesen
2005-10-31 18:06 ` Lee Revell
2005-10-31 22:09 ` Lee Revell
2005-10-31 19:09 ` Joe Seigh
2005-11-02 17:47 ` James Courtier-Dutton
2005-11-02 18:47 ` Lee Revell [this message]
[not found] <53M7O-7Se-33@gated-at.bofh.it>
2005-11-01 3:52 ` Robert Hancock
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1130957274.9163.1.camel@mindpipe \
--to=rlrevell@joe-job.com \
--cc=James@superbug.co.uk \
--cc=cfriesen@nortel.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.