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. > 3. Providing cas32 is risky. It tempts people to build lock-free > data structures with it, but the necessary memory barriers are > difficult to use right, and few people even realize that memory > barriers are necessary on some multiprocessor systems. You're right; this is another aspect of the old API that we probably need to rethink. In the past, apr_atomic_cas has implicitly included a memory barrier on many systems-- e.g., it uses the lock prefix when doing a cmpxchg on x86-- but this hasn't been guaranteed on all platforms. I'm not sure which is the right solution: have the API guarantee read and write ordering within the CAS function, or provide a memory separate memory barrier function. Any recommendations? Thanks, Brian
