From: "Christopher Friesen" <cfriesen@nortel.com>
To: Andi Kleen <ak@suse.de>
Cc: Ulrich Drepper <drepper@redhat.com>, Ingo Molnar <mingo@elte.hu>,
Thomas Gleixner <tglx@linutronix.de>,
Arjan van de Ven <arjan@infradead.org>,
David Singleton <dsingleton@mvista.com>,
Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org
Subject: Re: [patch 0/5] lightweight robust futexes: -V1
Date: Wed, 15 Feb 2006 13:49:21 -0600 [thread overview]
Message-ID: <43F385C1.9020508@nortel.com> (raw)
In-Reply-To: <200602151942.20494.ak@suse.de>
Andi Kleen wrote:
> On Wednesday 15 February 2006 18:50, Ulrich Drepper wrote:
>>Andi Kleen wrote:
>>
>>>e.g. you could add a new VMA flag that says "when one user
>>>of this dies unexpectedly by a signal kill all"
>>
>>"kill all"?
> It would solve the problem statement given by Ingo in the rationale
> for this kernel patch - cleaning up after a hanging yum.
>
> If there are any other problems this is intended to solve then they
> should be stated in the rationale.
"robust" mutexes isn't a new thing, so I assume Ingo didn't think he
needed to post the whole rationale.
Consider a group of tasks that want to use a mutex to control access to
data. If one of them dies while holding the mutex, the state of the
data is unknown and the mutex is left locked.
The goal is for the kernel to unlock the mutex, but the next task to
aquire it gets some special notification that the status is unknown. At
that point the task can either validate/clean up the data and reset the
mutex to clean (if it can) or it can give up the mutex and pass it on to
some other task that does know how to validate/clean up.
You want the speed of futexes if possible. You want to keep running.
You just want to know that the data protected by the mutex may not be
self-consistent.
Chris
next prev parent reply other threads:[~2006-02-15 19:50 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-15 15:17 [patch 0/5] lightweight robust futexes: -V1 Ingo Molnar
2006-02-15 15:22 ` Ingo Molnar
2006-02-15 17:35 ` Andi Kleen
2006-02-15 17:50 ` Ulrich Drepper
2006-02-15 18:42 ` Andi Kleen
2006-02-15 19:49 ` Christopher Friesen [this message]
2006-02-15 20:02 ` Andi Kleen
2006-02-15 20:13 ` Antonio Vargas
2006-02-15 20:25 ` Andi Kleen
2006-02-15 20:59 ` Ingo Molnar
2006-02-15 20:43 ` Ingo Molnar
2006-02-15 19:05 ` Daniel Walker
2006-02-15 19:11 ` Arjan van de Ven
2006-02-15 19:13 ` Daniel Walker
2006-02-15 21:31 ` Ingo Molnar
2006-02-16 15:43 ` Daniel Walker
2006-02-15 21:45 ` Andrew Morton
2006-02-15 22:14 ` Ingo Molnar
2006-02-17 21:59 ` Daniel Jacobowitz
2006-02-16 3:57 ` Darren Hart
2006-02-16 14:58 ` Johannes Stezenbach
2006-02-16 17:20 ` Ingo Molnar
2006-02-16 19:04 ` Daniel Walker
2006-02-17 9:09 ` Avi Kivity
2006-02-17 19:55 ` Johannes Stezenbach
2006-02-17 20:02 ` Arjan van de Ven
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=43F385C1.9020508@nortel.com \
--to=cfriesen@nortel.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=drepper@redhat.com \
--cc=dsingleton@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox