Date: Sat, 12 Jun 2004 17:49:17 -0700 From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> To: Robert Watson <rwatson@freebsd.org> Cc: Julian Elischer <julian@elischer.org> Subject: Re: reference counting.. continued.. Message-ID: <20040613004917.GC542@funkthat.com> In-Reply-To: <Pine.NEB.3.96L.1040612153110.90086I-100000@fledge.watson.org> References: <57800.1086807537@critter.freebsd.dk> <Pine.NEB.3.96L.1040612153110.90086I-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040613004917.GC542>