lkml.org 
[lkml]   [2002]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] New locking primitive for 2.5
    Dave Hansen wrote:
    >
    > Andrew Morton wrote:
    > > Robert Love wrote:
    > >>On Thu, 2002-02-07 at 10:38, Martin Wirth wrote:
    > >>Some of the talk I've heard has been toward an adaptive lock. These are
    > >>locks like Solaris's that can spin or sleep, usually depending on the
    > >>state of the lock's holder. Another alternative, which I prefer since
    > >>it is much less overhead, is a lock that spins-then-sleeps
    > >>unconditionally.
    > > I dunno. The spin-a-bit-then-sleep lock has always struck me as
    > > i_dont_know_what_the_fuck_im_doing_lock(). Martin's approach puts
    > > the decision in the hands of the programmer, rather than saying
    > > "Oh gee I goofed" at runtime.
    >
    > The spin-then-sleep lock could be interesting as a replacement for the
    > BKL in places where a semaphore causes performance degredation. In
    > quite a few places where we replaced the BKL with a more finely grained
    > semapore (not a spinlock because we needed to sleep during the hold),
    > instead of spinning for a bit, it would schedule instead. This was bad
    > :). Spin-then-sleep would be great behaviour in this situation.

    But surely you *knew*, from inspection, which code paths needed
    a spinning lock, and which code paths needed a sleeping lock?

    Assuming the answer is "yes" then a nice fix would be to use
    two separate locks - one which spins and one which sleeps.

    Now, if the resource which is being protected truly cannot
    be split up into spin-protected and sleep-protected sections
    then a lock which can be atomically converted from spinning to
    sleeping at the programmer's discretion seems appropriate.

    A dynamic lock which says "we've spun for too long, let's sleep"
    seems to be a tradeoff between programmer effort and efficiency,
    and a bad one at that.

    Possibly the locks could become more adaptive, and could, at
    each call site, "learn" the expected spintime. But it all seems
    too baroque to me.

    -
    -
    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:18    [W:0.031 / U:0.004 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site