While Boost.Atomic strives to implement the atomic operations from C++11 as faithfully as possible, there are a few limitations that cannot be lifted without compiler support:
atomic<T>results in undefined behavior: This means that any class containing a constructor, destructor, virtual methods or access control specifications is not a valid argument in C++98. C++11 relaxes this slightly by allowing "trivial" classes containing only empty constructors. Advise: Use only POD types.
memory_order_consumeonly affects computationally-dependent operations, but in general there is nothing preventing a compiler from transforming a computation dependency into a control dependency. A C++11 compiler would be forbidden from such a transformation. Advise: Use
memory_order_consumeonly in conjunction with pointer values, as the compiler cannot speculate and transform these into control dependencies.
memory_order_releaseneed to restrain reordering of memory operations only in one direction. Since there is no way to express this constraint to the compiler, these act as "full compiler barriers" in this implementation. In corner cases this may lead to worse code than a C++11 compiler could generate.
atomic<T>in shared memory only works correctly, if
atomic<T>::is_lock_free == true