apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From grega...@apache.org
Subject Re: request for comments: new atomic API
Date Mon, 15 Sep 2003 21:07:38 GMT
Brian Pane wrote:
> On Sat, 2003-09-13 at 07:29, Wan-Teh Chang wrote:
>>1. It seems that you intentionally do not want the add32, sub32,
>>and inc32 return a value.  Only the dec32 function returns a
>>value, and that value can only be used as a boolean (zero or
>>2. There is no atomic exchange function that atomically sets
>>the new value and returns the old value.  (This can be implemented
>>with the cas32 function in your API, so people can work around the
>>lack of the atomic exchange function.)
> The simple reason for both of these is that the design
> follows the original APR atomic API, which had void return
> codes for the add/inc calls and no exchange function.
> It wouldn't be too difficult to add an apr_atomic_xchg32.
> For the add/subtract/inc functions, it definitely would
> be nice to have the original value as a return code.  The
> only problem is that seems difficult to do this without
> making the functions more time-consuming.

I would add return values to all of them right off the bat.  It seemed like 
every time we came up with a new use for APR atomics, we needed a return value.

The original APR atomics were modeled after FreeBSD I believe, and that 
implementation isn't very useful.  The last time I searched thru the FreeBSD 
kernel code, the core didn't use these atomics much at all, but rather spin 
locks based on i386 xchg for Intel.  That should tell us something.

Then there's this other popular open source OS which has a much more technically 
useful set of atomics which set return values, but sadly an incompatible 
licence.  They are heavily used in that kernel.


View raw message