Date: Thu, 20 May 2004 13:56:36 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: arch@freebsd.org Subject: atomic reference counting primatives. Message-ID: <Pine.BSF.4.21.0405201340590.72391-100000@InterJet.elischer.org>
next in thread | raw e-mail | index | archive | help
This has been raised before but I've come across uses for it again and
again so I'm raising it again.
JHB once posted some atomic referenc counting primatives. (Do you still
have them John?)
Alfred once said he had soem somewhere too, and other s have commentted
on this before, but we still don't seem to have any.
every object is reference counted with its own code and
sometimes it's done poorly.
Some peiople indicated that there are cases where a generic refcounter
can not be used and usd this as a reason to not have one at all.
So, here are some possibilities..
my first "write it down without too much thinking" effort..
typedef {mumble} refcnt_t
refcnt_add(refcnt_t *)
Increments the reference count.. no magic except to be atomic.
int refcnt_drop(refcnt *, struct mutex *)
Decrements the refcount. If it goes to 0 it returns 0 and locks the
mutex (if the mutex is supplied)..
refcnt_init(refcnt_t *)
would simply set the counter to 0 if refcnt_t is defined as a simple
type, but could do more if a more complex refcount is used (say for
debugging)
debugging versions of the above might store all sorts of stuff in the
refcount.. (e.g. pid, __LINE__ __FUNCTION__ etc.)
vm->vm_exitingcnt)
If these were in place it would be a first step in
tightennign up some of the reference counting we see in the kernel
and there are several places I've seen over the last few years where
locks are used purely to allow reference counts to be manipulated.
thoughts....?
better ideas?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0405201340590.72391-100000>