apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <brian.p...@cnet.com>
Subject Re: request for comments: new atomic API
Date Sat, 13 Sep 2003 18:06:17 GMT
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



Mime
View raw message