On 5/2/07, Davi Arnaut <davi@xxxxxxxxxxxxx> wrote:The waits are queued, thus then can be "unqueued". It's quite simple toIt'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 futexesEvents are simple. A event is either signaled or not. A futex value 0 means
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.If it's really worth, I have no problem with it.
So this would have to be changed, too.