lkml.org 
[lkml]   [2017]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2/6] locking: Introduce range reader/writer lock
    On Thu, Apr 06, 2017 at 01:46:16AM -0700, Davidlohr Bueso wrote:
    > +/*
    > + * Range/interval rw-locking
    > + * -------------------------
    > + *
    > + * An interval tree of locked and to-be-locked ranges is kept. When a new range
    > + * lock is requested, we add its interval to the tree and store number of
    > + * intervals intersecting it to 'blocking_ranges'.

    You're again confusing semantics with implementation here.

    > For the reader case,
    > + * 'blocking_ranges' is only accounted for if the intersecting range is
    > + * marked as a writer. To achieve mutual exclusion of arbitrary ranges, we
    > + * guarantee that task is blocked until there are no overlapping ranges in the
    > + * tree.
    > + *
    > + * When a range is unlocked, we again walk intervals that overlap with the
    > + * unlocked one and decrement their 'blocking_ranges'. Naturally, we wake up
    > + * owner of any range lock whose 'blocking_ranges' drops to 0. Wakeup order
    > + * therefore relies on the order of the interval tree -- as opposed to a
    > + * more traditional fifo mechanism.

    Which order is that? (I could of course go read the interval tree code,
    but it shouldn't be too much effort to mention it here).

    > There is no lock stealing either, which
    > + * prevents starvation and guarantees fairness.

    So no lock stealing has always been very bad for performance. So are you
    sure people will not frob this back in?


    > +#ifndef _LINUX_RANGE_RWLOCK_H

    Still don't like the name... rwlock_t is a spinlock.

    \
     
     \ /
      Last update: 2017-04-06 12:25    [W:2.194 / U:0.236 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site