Re: reference counting.. continued..

From: John-Mark Gurney (gurney_j_at_resnet.uoregon.edu)
Date: 06/13/04

  • Next message: Julian Elischer: "Re: reference counting.. continued.."
    Date: Sat, 12 Jun 2004 17:49:17 -0700
    To: Robert Watson <rwatson@freebsd.org>
    
    

    Robert Watson wrote this message on Sat, Jun 12, 2004 at 15:33 -0400:
    > > Our reference counts will almost invariably be integral properties of
    > > our objects and therefore has to interact with the remaining object
    > > locking.
    >
    > I don't have a strong feeling about the general need for a refcount API,
    > but I can confirm that many of the interesting objects in the kernel
    > wouldn't lend themselves to such an API. There are many cases where we'll
    > want to protect the reference count using an existing lock, in which case
    > locking built into the reference count API becomes a liability. Socket
    > reference counting is one example of this: in some ways, it's a general
    > purpose reference count, but the GC behavior is specific to sockets and
    > depends on additional uncounted references from file descriptors and the
    > prototocol layer.

    In working on locking down KQ, I came across the same problem. What I
    ended up doing is creating an object that kept a copy of struct mtx *
    in it. When I created the object, you could either pass in a NULL, and
    a fresh mutex would be created, or you could pass in your own object's
    struct mtx *... This makes it more capable of flexibility and only
    requires a lock/unlocked arg...

    Just a thought...

    -- 
      John-Mark Gurney				Voice: +1 415 225 5579
         "All that I will do, has been done, All that I have, has not."
    _______________________________________________
    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: Julian Elischer: "Re: reference counting.. continued.."

    Relevant Pages

    • cvs-src summary for June 7-14
      ... Here's the summary - hope you like locking. ... You can get old summaries, and an HTML version of this one, at ... Poul-Henning Kamp committed reference counting for the tty code; ...
      (freebsd-current)
    • Re: Threads - why isnt a whole object locked when ...?
      ... All of your questions are answerable by pointing out that you have an incorrect mental model of what it means to "lock" something. ... That is, while it's entirely sensible to people who are familiar with standard thread synchronization techniques, in reality it's not actually locking anything. ... Instead, it's using the reference as a sort of traffic signal for other threads, which are cooperating, to respect. ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: multi threading in C#
      ... guarantees that no-one else can screw things up by locking on it ... reference example, "listLock" is the reference only you have access to, and the implication is that "queue" is a reference that others have access to. ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: [PATCH] reiserfs: Expand i_mutex to enclose lookup_one_len
      ... version of the code where I kept a reference to /.reiserfs_priv/xattrs. ... Then I decided that .reiserfs_priv was all I needed to cache (to avoid ... recursive i_mutex locking on the fs root) and dropped the caching of ...
      (Linux-Kernel)
    • Re: [RFC] ext3/jbd race: releasing in-use journal_heads
      ... reference in b_jcount. ... Now if you unfile a buffer from the list you 'get back' it's ... the proper list locking so that two different callers cannot 'get back' one ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)