From owner-freebsd-smp Tue Oct 31 10:23: 7 2000 Delivered-To: freebsd-smp@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 5F67D37B4C5 for ; Tue, 31 Oct 2000 10:23:01 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id NAA93621; Tue, 31 Oct 2000 13:21:45 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Tue, 31 Oct 2000 13:21:45 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Cedric Berger Cc: freebsd-smp@FreeBSD.org Subject: Re: Reference count invariants in a fine-grained threaded environment In-Reply-To: <39FF0AC0.86A3A950@wireless-networks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 31 Oct 2000, Cedric Berger wrote: > > Rules for interactions between mutexes and reference-counted kernel > > objects: > > > > Assumptions: > > > > - Objects with reference counts have a mutex that can protect their > > reference count, and possibly other variables (or other instances). For > > example, struct cred might have a mutex per instance, but all struct > > prison's might use the same mutex. > > Is there not a cheaper way to manage reference count then using mutexes? > I would guess that all architectures must have hardware support (i.e. special > assembly instruction) to atomically increment/decrement+read a 32-bit value > in a multiprocessor environment As long as parent references are properly managed, I believe that this is correct (although I haven't attempted to rigorously explore all the cases): as long as any modification to the reference count is (a) done with an existing valid reference, and (b) done atomically, it should be safe. If you get back 0 in your atomic decrement, then it is safe to release the object. In the case of the prison code, I'm also using a mutex to protect the global data structure (list) that holds all prison structures so that they can be managed directly by jailid: to garbage collect the list entry, you must hold the list mutex to maintain integrity, and also to prevent new references from materializing via the list as it is an implicit reference acquisition mechanism. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message