lkml.org 
[lkml]   [2002]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: furwocks: Fast Userspace Read/Write Locks
    Date
    On Friday 08 March 2002 04:21 am, Peter Wächtler wrote:
    > Rusty Russell wrote:
    > > In message <20020307153228.3A6773FE06@smtp.linux.ibm.com> you write:
    > >>On Thursday 07 March 2002 07:50 am, Arjan van de Ven wrote:
    > >>>Rusty Russell wrote:
    > >>>>This is a userspace implementation of rwlocks on top of futexes.
    > >>>
    > >>>question: if rwlocks aren't actually slower in the fast path than
    > >>>futexes,
    > >>>would it make sense to only do the rw variant and in some userspace
    > >>>layer
    > >>>map "traditional" semaphores to write locks ?
    > >>>Saves half the implementation and testing....
    > >>
    > >>I m not in favor of that. The dominant lock will be mutexes.
    > >
    > > To clarify: I'd love this, but rwlocks in the kernel aren't even
    > > vaguely fair. With a steady stream of overlapping readers, a writer
    > > will never get the lock.
    > >
    > > Hope that clarifies,
    >
    > But you talk about the current implementation, don't you?
    > Is there something to prevent an implementation of rwlocks in the
    > kernel, where a wrlock will lock (postponed) further rdlock requests?
    >
    > I mean: the wrlocker prevents newly rdlocks to succeed and waits for the
    > current rdlockers to release the lock an then gets the lock..

    Correct, the idea is to have four functionalities.

    (a) writer preference
    if any writer is waiting then wake that one up.
    (b) reader preference
    if any reader is waiting wait up all the readers in the queue
    (c) fifo preference
    if the first waiter is a writer wait it up, otherwise wake up all readers
    (d) fifo-fair preference
    like (c), but only wake up readers until the next writer is encountered

    (a) - (c) can be implemented with Rusty's 2 user-ueue approach as long
    as the wakeup type is always the same. The last one can't (?).

    In the kernel this is easy to implement, but the trouble is the status
    word in user space, still thinking about it.

    It also requires compare and swap.

    Also we still need the verdict on the FUTEX_UP and FUTEX_UP_FAIR issue.
    Rusty, I noticed you have not stated anything to my combining the two things
    into FUTEX V submission. Could you respond with your take on these issues.

    --
    -- Hubertus Franke (frankeh@watson.ibm.com)
    -
    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: 2005-03-22 13:24    [W:0.027 / U:90.612 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site