[EMAIL PROTECTED] wrote:
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
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.
Do you know of an efficient way to return either the old
or the new value while still maintining atomicity? It can
be done by using CAS to replace the old value with the new
value, but I've been trying to move away from that design
because it adds more overhead. It's easy--and reasonably
efficient--to set a return code based on whether the new
value is zero, but using logic like this:
atomic add/sub/inc/dec operation;
if (zero flag is set in CPU) {
result = 0;
}
else {
result = 1;
}
But I haven't figured out a way to return the actual value
(either the old or the new value) without using locking
or a CAS operation.
Brian
