From owner-freebsd-arch Mon Nov 12 16:23:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 55EC337B416; Mon, 12 Nov 2001 16:23:27 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id fAD0Msb07370; Mon, 12 Nov 2001 16:22:54 -0800 (PST) (envelope-from dillon) Date: Mon, 12 Nov 2001 16:22:54 -0800 (PST) From: Matthew Dillon Message-Id: <200111130022.fAD0Msb07370@apollo.backplane.com> To: Julian Elischer Cc: John Baldwin , freebsd-arch@FreeBSD.ORG, Robert Watson , Terry Lambert Subject: Re: cur{thread/proc}, or not. References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :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