[EMAIL PROTECTED] wrote:
If apr_atomic_inc32 returns something, it would be much more useful to have it return the old value of the variable. That way you can atomically allocate a slot in an array via:
you're the boss; fwliw, that sounds right to me
IIRC the main objection to having this set of functions return something was that we didn't have a fast implementation. Now I've got a working Intel version using the xadd instruction (which requires at least an i486...is that a big deal?).
I don't think it is a big deal, but I'm curious about whether some folks will need to do both
a) --enable-nonportable-atomics
b) specify architecture as 486 with CFLAGS to override default of 386
fwiw, I'm using gcc -O2 to get the inline attribute to kick in. Regardless of what we do with the API, we should commit the inline attribute IMO because it is a nearly free performance boost.
Inlining isn't going to help in the real world* since the implementation is hidden inside APR. Hide your new add32 inside APR and performance is going to go south.
*except for helper functions used in the implementation of atomics, of course
