Re: Read Copy Update

From: Doug Rabson (dfr_at_nlsystems.com)
Date: 02/19/04

  • Next message: Ted Unangst: "Re: Read Copy Update" 
    To: Jeff Roberson <jroberson@mail.chesapeake.net>
Date: Thu, 19 Feb 2004 09:02:35 +0000

    On Wed, 2004-02-18 at 23:26, Jeff Roberson wrote:
    > On Wed, 18 Feb 2004, Doug Rabson wrote:
    >
    > > So, I was reading the latest installment of the SCO soap on slashdot
    > > today (bizarre - they seem to be claiming that they own all code that
    > > was ever linked to a System V kernel) and I ended up trying to figure
    > > out exactly what this RCU thing is that they claim is infringing their
    > > right to obtain money with menaces.
    > >
    > > I read one of the original papers at
    > > http://www.rdrop.com/users/paulmck/paper/rclockpdcsproof.pdf and its a
    > > surprisingly simple idea. Basically for certain data structures which
    > > are read-mostly, you can make the entire read path lock-free at the
    > > expense of making updates quite a bit more expensive. They claim that
    > > its much faster than reader-writer locks both for light contention and
    > > for heavy contention.
    > >
    > > I imagine that a FreeBSD implementation of RCU wouldn't actually be too
    > > hard and it might be well worth it as an alternative way of managing
    > > concurrency, e.g. for the routing cache and the name cache (and probably
    > > lots of other things).
    > >
    >
    > I've looked into this a bit myself. My general feeling is that it would
    > not be terribly difficult to do, but I would prefer to start with stronger
    > primitives and work our way into more efficient mechanisms. I say this
    > for two reasons. First, as a general rule of optimizations, you only
    > optimize the things that need it. I think we should wait and measure
    > contention and then optimize things. Secondly, we need to get more
    > confidence in the correctness of simpler mechanisms in most subsystems
    > before we go to something more complex. It will be easier to move to RCU
    > once a subsystem is already protected by mutexes.
    >
    > I think that this is a good path to go down, but I really don't think
    > we're ready yet. I'd rather see energy spent protecting code than
    > building more infrastructure.

    I completely agree. I was just musing about this as a future addition to
    the locking toolbox. Its certainly not worth trying before enough of the
    kernel is outside the giant lock to make it worthwhile.

    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Ted Unangst: "Re: Read Copy Update"