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: 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: [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)
    • Re: [PATCH] sysfs: kill an extra put in sysfs_create_link() failure path
      ... >>> Locking. ... >> down the reference later. ... Oops, somehow thought you were talking about allocating it first. ...
      (Linux-Kernel)
    • Re: multi threading in C#
      ... reference example, "listLock" is the reference only you have access to, ... and the implication is that "queue" is a reference that others have access ... Only the ProducerConsumer class has access to listLock. ... to replace listLock with a different type of locking type, ...
      (microsoft.public.dotnet.languages.csharp)