Date: Tue, 12 Dec 2000 19:14:56 -0800 From: Jake Burkholder <jburkhol@home.com> To: Jason Evans <jasone@canonware.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: An opaque refcount type Message-ID: <20001213031456.280D9BA7D@io.yi.org> In-Reply-To: Message from Jason Evans <jasone@canonware.com> of "Tue, 12 Dec 2000 18:34:14 PST." <20001212183414.K2312@canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Tue, Dec 12, 2000 at 12:24:50PM -0800, John Baldwin wrote: > > Here's another bikeshed war for everyone to get in on: I've implemented a > > relatively light weight and very simple opaque reference counter. It defines > > an opaque refcount_t type. In the INVARIANTS case, this maps to a structure > > that contains an integer and a mutex. The mutex is used to protect the > > integer count as well as several KASSERT()'s. In the non-INVARIANTS case, it > > maps to a single integer on all of our current platforms (x86, alpha, ia64) and > > is managed via atomic operations. It defines a rather simple API: > > > > void refcount_init(refcount_t *count, u_int value) > > - Initializes the reference counter and sets its inital count to 'value'. > > void refcount_destroy(refcount_t *count) > > - Cleans up any internals used in a refcount, frees resources, etc. > > void refcount_acquire(refcount_t *count) > > - Atomically bump the reference count by one. > > int refcount_release(refcount_t *count) > > - Atomically decerement the reference count by one and return true if the > > count drops to zero. > > As at least John and Alfred know, I'm opposed to an atomic refcount type, > for at least the following reasons: > > 1) The number of bits of accuracy varies from platform to platform. It > seems that the least common denominator we'd need to settle on is 24 > bits (sparc64), which is enough for most, but not all uses. This is the > kernel we're talking about here; I don't like the uncertainty of the > accuracy. Maybe 16.7 million is enough accuracy, but... > Where does the 24 bits for sparc64 come from? According to the ultra-sparc manual it has an atomic compare and swap instruction, casx, which operates on a 64 bit value. AFAIK only sparc32 is restricted to 24 bits, because of the ldstub instruction. 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?20001213031456.280D9BA7D>