/usr/include/atomic.h and memory ordering
Hi,
I've just posted a port of the Boost shared pointer base class to the Boost mailing list, and some of the feedback I have got expresses concerns about meory ordering of atomic_inc_32[_nv], atomic_dec_32_nv and atomic_cas_32 on SPARC.
From all the research I've done on the techniques used in these calls, they look fine for use in reference counted shared pointers in a multi-CPU environment (mostly because they're all implemented in terms of the CAS instruction). The manual pages do not state anything about memory ordering, but do suggest that these functions are suitable for lock-free reference counting.
So: could somebody with a little more SPARC-fu than me please chime in as to whether or not any memory barriers are needed when using these functions for reference counting.
Thanks,
Michael
[844 byte] By [
r1mikey] at [2007-11-26 8:27:10]
# 1
> Hi,
>
> I've just posted a port of the Boost shared pointer
> base class to the Boost mailing list, and some of the
> feedback I have got expresses concerns about meory
> ordering of atomic_inc_32[_nv], atomic_dec_32_nv and
> atomic_cas_32 on SPARC.
>
> From all the research I've done on the techniques
> used in these calls, they look fine for use in
> reference counted shared pointers in a multi-CPU
> environment (mostly because they're all implemented
> in terms of the CAS instruction). The manual pages do
> not state anything about memory ordering, but do
> suggest that these functions are suitable for
> lock-free reference counting.
>
> So: could somebody with a little more SPARC-fu than
> me please chime in as to whether or not any memory
> barriers are needed when using these functions for
> reference counting.
>
> Thanks,
> Michael
If you look closely at the implementation of the atomic_xxx api functions, you will notice that they are all naked! Take a look at the membar_xxx api's... You can use them in "conjunction" with the atomic_xxx api to get the ordering you desire...
For instance, to get an atomic increment with acquire semantics you would use something like this:
void xatomic_inc_32_acquire(...) {
atomic_inc_32(...)
membar_enter();
}
To get atomic decrements* with release semantics you could use something like this:
void xatomic_dec_32_release(...) {
membar_exit();
atomic_dec_32(...)
}
Believe me, if you use the atomic_xxx api without using explicit memory barrier functionality, you will drive your lock-free reference counting algorithm right off a cliff!
Any thoughts?
*You have to remember that the type if barrier you need for decrements is dependant on the result of the decrement. For instance, if the result of the decrement is going to be < 1, you need acquire semantics?If the result is going to be > 0, you need release semantics:
http://groups.google.com/group/comp.programming.threads/msg/38999f4711677160
# 3
> Hi again!
>
> I found this post
> http://unix.derkeiler.com/Newsgroups/comp.unix.program
> mer/2005-06/0490.html on a trawl through the 'net,
> which seems to suggest that for what Boost shared
> pointers are using atomic ops for we should be OK.
You抮e going to need to add the proper memory barriers in your implementation of Boost shared_ptr because it needs to maintain proper memory visibility semantics.
[...]
