Messages in this thread | | | Date | Wed, 02 May 2007 14:05:51 -0300 | From | Davi Arnaut <> | Subject | Re: [patch 14/22] pollfs: pollable futex |
| |
Ulrich Drepper wrote: > On 5/2/07, Davi Arnaut <davi@haxent.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. The waits are queued, thus then can be "unqueued". It's quite simple to extend futex_wait_queue() to support this, but again you are thinking of locks while what I want is fast events. > 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. Events are simple. A event is either signaled or not. A futex value 0 means not signaled, 1+ signaled. > And you wrote that currently each futex needs its own file descriptor. > So this would have to be changed, too. If it's really worth, I have no problem with it.
-- Davi Arnaut - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |