Date: Tue, 31 Oct 2000 11:15:14 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Cedric Berger <cedric@wireless-networks.com> Cc: freebsd-smp@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org> Subject: Re: Reference count invariants in a fine-grained threaded enviro Message-ID: <XFMail.001031111514.jhb@FreeBSD.org> In-Reply-To: <39FF0AC0.86A3A950@wireless-networks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31-Oct-00 Cedric Berger wrote: > > > Robert Watson 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 They don't. The ia64 has a 'fetchadd' instruction, but x86 and alpha don't have instructions for this, AFAIK. You can implement it using the atomic_cmpset() functions however. Of course, what happens if you decrement a reference and while you are freeing the object someone else obtains a reference to it? Granted, this shouldn't be possible since if no one can get to an object, no one should be able to find the object to allocate a reference to it.... > Cedric -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.001031111514.jhb>