From owner-freebsd-arch@FreeBSD.ORG Mon Sep 26 21:24:52 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 791A116A429 for ; Mon, 26 Sep 2005 21:24:52 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFDDF43D48 for ; Mon, 26 Sep 2005 21:24:49 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.233] (Not Verified[10.50.41.233]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 26 Sep 2005 17:40:47 -0400 From: John Baldwin To: arch@FreeBSD.org Date: Mon, 26 Sep 2005 17:26:03 -0400 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509261726.04372.jhb@FreeBSD.org> Cc: Subject: atomic_fetchadd_int() and a simple refcount API for non-complicated refcounts X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2005 21:24:52 -0000 I have two patches here for review. They have been tested on i386, alpha, and sparc64 so far. The first patch adds a new atomic operation: atomic_fetchadd_int() (and its alias: atomic_fetchadd_32()). The operation pretty much maps directly onto the x86 xadd instruction added with the 486. I believe it also maps directly onto the fetchadd instruction on ia64 (from whence it got its name). (Note that the ia64 instruction can only take a fixed set of immediate operands to add by such as 1, -1, 2, -2, 4, -4, etc. up to 64 and -64 IIRC.) On architectures where I wasn't sure how to do the inline assembly (ia64, ppc, arm) it just uses a atomic_cmpset() loop, but that can be changed later as an optimization easily enough. Having this new primitive allows for construction of simple standalone reference counts that are cheaper than ones protected by a mutex (1 atomic op vs at least 2). Thus, I used atomic_fetchadd() to build a very simple refcount API that operates on integers. It has an init method to set the initial value, an acquire method to bump a refcount, and a release method to drop a reference. The release method returns non-zero when the last reference is dropped. I used this API to implement the reference counts for ucreds, plimits, pargs, and mbuf clusters (though I know andre@ has plans in the works to hack on the mbuf ones further, so those changes might just be temporary). Also, I know that andre@ wants atomic_fetchadd() for the changes he will be doing. Patches are at the URLS below: http://www.FreeBSD.org/~jhb/patches/atomic_fetchadd.patch http://www.FreeBSD.org/~jhb/patches/refcount_cvs.patch FAQ: Q: The refcount API is too simple and doesn't handle the snortzel-foo edge case!!!! A: Yes. It's not meant to be all-singing and all-dancing. It is simply available as one tool that is available for use. More complex reference counting schemes can be built using atomic_fetchadd() or other more complex primitives such as mutexes if needed. Q: I think the name 'fetchadd' sucks!! A: Your opinion has been noted. Q: Will this destroy the ABI? A: No. The refcount_*() functions are all inlines. The only thing that might break the ABI might be changes to structures to remove mutexes or mutex pointers, but that part of a change can always be left out if this were merged across a branch. Q: Will this be in 6.0? A: Hopefully. The sooner this gets reviewed the better the chances. Due to the previous question, it is possible to merge it to RELENG_6 after 6.0 is released anyway. Q: What color is a snortzel-foo? A: I don't know, probably some sort of lavender. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org