From: Daniel Walker <dwalker@mvista.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
Ulrich Drepper <drepper@gmail.com>,
Arjan van de Ven <arjan@infradead.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 5/5] futex: fix miss ordered wakeups
Date: Thu, 12 Jun 2008 16:06:02 -0700 [thread overview]
Message-ID: <1213311963.16459.89.camel@localhost.localdomain> (raw)
In-Reply-To: <alpine.LFD.1.10.0806130023440.3193@apollo.tec.linutronix.de>
On Fri, 2008-06-13 at 00:43 +0200, Thomas Gleixner wrote:
> On Thu, 12 Jun 2008, Daniel Walker wrote:
>
> >
> > On Thu, 2008-06-12 at 21:55 +0200, Thomas Gleixner wrote:
> > > Also your interpretation of the POSIX requirement is very
> > > questionable:
> > >
> > > "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."
> >
> > The key is "scheduling policy" .. When the mutex is un-blocked the next
> > task to run is the same as if the scheduler was selecting tasks from the
> > list of blocked tasks .. For Linux, that means the highest priority
> > tasks should be selected.. So it's no more acceptable for the scheduler
> > to priority invert some tasks than it is for the futex to do it.
>
> Sigh, when do you actually get a gripe that the default futex
> implementation does not and can not guarantee that at all and therefor
> your "correctness" patch is as important as a bag of rice which
> toopled over in China ?
Well, the last email I got from Arjan said this,
".. Don't look at the release path... look at the acquire path.
If a thread sees the futex is free, it'll take it, without even going
to the kernel at all."
And yes, I understand that fully.
> Provide answers to the real questions I asked more than once:
>
> What's the real world problem ? Who cares about that - except you ?
Any application which starts a thread, and later changes the priority
can observe the miss-ordering.. That's pretty common..
Daniel
next prev parent reply other threads:[~2008-06-12 23:06 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-11 20:49 [PATCH 1/5] futex: checkpatch cleanup Daniel Walker
2008-06-11 20:49 ` [PATCH 2/5] futex: update prio on requeue Daniel Walker
2008-06-12 5:22 ` Peter Zijlstra
2008-06-11 20:49 ` [PATCH 3/5] mutex debug: add generic blocked_on usage Daniel Walker
2008-06-12 5:25 ` Peter Zijlstra
2008-06-12 13:21 ` Daniel Walker
2008-06-11 20:49 ` [PATCH 4/5] rtmutex: " Daniel Walker
2008-06-11 20:49 ` [PATCH 5/5] futex: fix miss ordered wakeups Daniel Walker
2008-06-12 6:07 ` Peter Zijlstra
2008-06-12 13:22 ` Daniel Walker
2008-06-12 13:57 ` Peter Zijlstra
2008-06-12 14:04 ` Daniel Walker
2008-06-12 8:56 ` Thomas Gleixner
2008-06-12 13:30 ` Daniel Walker
2008-06-12 13:33 ` Thomas Gleixner
2008-06-12 13:44 ` Daniel Walker
2008-06-12 15:24 ` Thomas Gleixner
2008-06-12 15:56 ` Daniel Walker
2008-06-12 19:55 ` Thomas Gleixner
2008-06-12 22:09 ` Daniel Walker
2008-06-12 22:43 ` Thomas Gleixner
2008-06-12 23:06 ` Daniel Walker [this message]
2008-06-12 23:30 ` Thomas Gleixner
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=1213311963.16459.89.camel@localhost.localdomain \
--to=dwalker@mvista.com \
--cc=arjan@infradead.org \
--cc=drepper@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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.