From owner-freebsd-arch Tue Dec 12 19:16:18 2000 From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 19:16:15 2000 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from io.yi.org (unknown [24.70.218.157]) by hub.freebsd.org (Postfix) with ESMTP id 318B437B400; Tue, 12 Dec 2000 19:16:15 -0800 (PST) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 280D9BA7D; Tue, 12 Dec 2000 19:14:56 -0800 (PST) X-Mailer: exmh version 2.1.1 10/15/1999 To: Jason Evans Cc: John Baldwin , arch@FreeBSD.ORG Subject: Re: An opaque refcount type In-Reply-To: Message from Jason Evans of "Tue, 12 Dec 2000 18:34:14 PST." <20001212183414.K2312@canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Dec 2000 19:14:56 -0800 From: Jake Burkholder Message-Id: <20001213031456.280D9BA7D@io.yi.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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