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 nonzero).
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.
Greg
