apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From grega...@apache.org
Subject Re: apr_atomic stuff... desireable to return values from more functions
Date Thu, 04 Dec 2003 00:09:00 GMT
Jeff Trawick wrote:
> This is still unresolved.
> 
> See message <3F6665B4.6020906@cnet.com> (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

Mime
View raw message