atomic_fetchadd_int() and a simple refcount API for non-complicated refcounts
From: John Baldwin (jhb_at_FreeBSD.org)
Date: 09/26/05
- Previous message: Maxim Konovalov: "Re: Bridges"
- Next in thread: Andre Oppermann: "Re: atomic_fetchadd_int() and a simple refcount API for non-complicatedrefcounts"
- Reply: Andre Oppermann: "Re: atomic_fetchadd_int() and a simple refcount API for non-complicatedrefcounts"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: arch@FreeBSD.org Date: Mon, 26 Sep 2005 17:26:03 -0400
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 <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"
- Previous message: Maxim Konovalov: "Re: Bridges"
- Next in thread: Andre Oppermann: "Re: atomic_fetchadd_int() and a simple refcount API for non-complicatedrefcounts"
- Reply: Andre Oppermann: "Re: atomic_fetchadd_int() and a simple refcount API for non-complicatedrefcounts"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
