Date: Tue, 31 Oct 2000 13:21:45 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Cedric Berger <cedric@wireless-networks.com> Cc: freebsd-smp@FreeBSD.org Subject: Re: Reference count invariants in a fine-grained threaded environment Message-ID: <Pine.NEB.3.96L.1001031131603.58688A-100000@fledge.watson.org> In-Reply-To: <39FF0AC0.86A3A950@wireless-networks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1001031131603.58688A-100000>