lkml.org 
[lkml]   [2007]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 14/22] pollfs: pollable futex
    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.

    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-05-02 18:49    [W:0.024 / U:210.048 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site