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
