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.

-garrett


Mime
View raw message