Jeff Trawick wrote:
This is still unresolved.

See message <[EMAIL PROTECTED]> (subject "Re: request for comments: new atomic API", 9/15/2003 9:21 PM EST) for where a previous conversation on this was left dangling.

re: apr_atomic_inc32()
IMHO, this guy just *has* to return information to specify whether or not the value became non-zero due to this thread's call.

<lurker wakes up, probably one of the conversation danglers>

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:

my_index = apr_atomic_inc32(&global_index);
if (my_index < max_index) {
   use my_index - this thread is the exclusive owner
}
else {
   reset global_index from max_index to 0 via apr_atomic_cas32()
}

Oviously that won't work if it returns a boolean.

We could use that to implement a lock-free post log in mod_specweb99, along with some shared memory stuff. I think Madhu would be interested, given his recent encounter with SysV sems :)

re: apr_atomic_add32(),apr_atomic_sub32()
Maybe the answer is that if the app needs the information that could have been returned by APR, it can just use apr_atomic_cas32(), and it is fine to have these void functions (though is anybody really going to use them?).

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?).


The attached test program running 1,000,000 iterations of various versions of apr_atomic_add yields the following minimum user times on my ThinkPad (1.8G P4)

existing code:                                          90 ms
existing code plus the "inline" attribute:              70 ms
xadd version, loop exit checks "counter", same as the
              existing code driver (not atomic):        80 ms
xadd version, loop exit checks return value (atomic)    70 ms

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.

Greg

<<inline: test_atomic.c>>

Reply via email to