Re: atomic_fetchadd_int() and a simple refcount API for non-complicatedrefcounts
From: Andre Oppermann (andre_at_freebsd.org)
Date: 09/26/05
- Previous message: John Baldwin: "atomic_fetchadd_int() and a simple refcount API for non-complicated refcounts"
- In reply to: John Baldwin: "atomic_fetchadd_int() and a simple refcount API for non-complicated refcounts"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 26 Sep 2005 23:47:36 +0200 To: John Baldwin <jhb@FreeBSD.org>
John Baldwin wrote:
>
> 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
I have the i386 and amd64 versions of atomic_fetchadd running in my tree
for about a week. Works fine so far. ;-)
Please don't convert the mbuf cluster refcount to the refcount API. I
can do my commit reworking mbuf ref counting right after you commit adding
the new atomic_fetchadd function. That way we can save one step and
I have less trouble re-integrating my tree with HEAD.
-- Andre > 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 <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" _______________________________________________ freebsd-arch@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arch To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
