Date: Mon, 12 Nov 2001 16:22:54 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
To: Julian Elischer <julian@elischer.org>
Cc: John Baldwin <jhb@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG, Robert Watson <rwatson@FreeBSD.ORG>, Terry Lambert <tlambert2@mindspring.com>
Subject: Re: cur{thread/proc}, or not.
Message-ID: <200111130022.fAD0Msb07370@apollo.backplane.com>
References: <Pine.BSF.4.21.0111121552290.94926-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:we should re-examine teh 'refcount' API
:
:it's a very basic type and gettin gmore-so all the time..
:we can affort to have a 'standard' 'safe' way of doing reference counts.
:
Well, the question we face here is: should a refcount API be self
contained - apply only to ref counts, or should it be interlockable
with other functionality?
The best example of what I'm asking here can be found by observing
the existing vnode interlock. A single interlock mutex in each vnode
currently handles a bunch of chores: (1) It locks v_usecount
flags, (2) it interlocks the higher-level lockmgr lock, and (3) it
interlocks certain combined operations.
The current refcount API that John proposes would not be sufficient
to be useful for the vnode v_usecount, but it probably would be
sufficient for something like the ucred cr_ref count.
What about other structures in the system? Do we need self-contained
ref counts ala ucred, or do we need interlocking ref counts ala vnode?
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200111130022.fAD0Msb07370>