atomic_fetchadd_int() and a simple refcount API for non-complicated refcounts

[John Baldwin]

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 at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org