[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a36005b50705020946x6cc1cb96r9ddd2b364ba168d7@mail.gmail.com>
Date: Wed, 2 May 2007 09:46:53 -0700
From: "Ulrich Drepper" <drepper@...il.com>
To: "Davi Arnaut" <davi@...ent.com.br>
Cc: "Andrew Morton" <akpm@...ux-foundation.org>,
"Davide Libenzi" <davidel@...ilserver.org>,
"Linus Torvalds" <torvalds@...ux-foundation.org>,
"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [patch 14/22] pollfs: pollable futex
On 5/2/07, Davi Arnaut <davi@...ent.com.br> wrote:
> It's quite easy to implement this scheme by write()ing the futexes all
> at once but that would break the one futex per fd association. For
> atomicity: if one of the futexes can't be queued, we would rollback
> (unqueue) the others.
>
> Sounds sane?
I don't know how you use "unqueue" in this context. If a queued futex
is one which is /locked/ by te call, then yes, this is the semantics
needed. Atomically locking a number of futexes means that if one of
the set cannot be locked all operations done to lock the others have
to be undone. It's an all-or-nothing situation.
Locking is not as easy as you might think, though. For non-PI futexes
there is deliberately no protocol in place describing what "locked"
means. The locking operation has to be customizable. This is what
the FUTEX_OP_* stuff is about.
And you wrote that currently each futex needs its own file descriptor.
So this would have to be changed, too.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists