apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject Re: request for comments: new atomic API
Date Sun, 14 Sep 2003 13:28:01 GMT
Brian Pane wrote:

>>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?

I'd say that it should be documented to include any memory barriers that 
are needed, I mean that is a portability concern, and APR is a 
portability library.  I see a lot of people assuming that the atomic API 
would take care of that for them anyway, so we might as well document 
that it does and remove any doubt.


View raw message