|
Home | Libraries | People | FAQ | More |
While Boost.Atomic strives to implement the atomic operations from C++11 and later as faithfully as possible, there are a few limitations that cannot be lifted without compiler support:
atomic<> template needs an initialization
constructor that performs the necessary conversion. This makes atomic<>
a non-aggregate type and prohibits aggregate initialization syntax (atomic<int> a = {10}).
Boost.Atomic does support direct and unified
initialization syntax though. Advice:
Always use direct initialization (atomic<int> a(10))
or unified initialization (atomic<int> a{10})
syntax.
constexpr
for some types: For value types other than integral types and
bool, atomic<> initializing constructor needs
to perform runtime conversion to the storage type. This limitation may
be lifted for more categories of types in the future.
atomic<>,
the default constructor must also be defined. In C++03 the constructor
cannot be defined as defaulted and therefore it is not trivial. In C++11
the constructor is defaulted (and trivial, if the default constructor of
the value type is). In any case, the default constructor of atomic<>
performs default initialization of the atomic value, as required in C++11.
Advice: In C++03, do not use Boost.Atomic in contexts where trivial default constructor
is important (e.g. as a global variable which is required to be statically
initialized).
memory_order_consume
only affects computationally-dependent operations, but in general there
is nothing preventing a compiler from transforming a computation dependency
into a control dependency. A fully compliant C++11 compiler would be forbidden
from such a transformation, but in practice most if not all compilers have
chosen to promote memory_order_consume
to memory_order_acquire
instead (see this
gcc bug for example). In the current implementation Boost.Atomic
follows that trend, but this may change in the future. Advice:
In general, avoid memory_order_consume
and use memory_order_acquire
instead. Use memory_order_consume
only in conjunction with pointer values, and only if you can ensure that
the compiler cannot speculate and transform these into control dependencies.
memory_order_acquire/memory_order_consume and memory_order_release need to restrain
reordering of memory operations only in one direction. Since in C++03 there
is no way to express this constraint to the compiler, these act as "full
compiler barriers" in C++03 implementation. In corner cases this may
result in a slightly less efficient code than a C++11 compiler could generate.
Boost.Atomic will use compiler intrinsics,
if possible, to express the proper ordering constraints.
memory_order_seq_cst)
to generate code. Not only this reduces performance, this may hide bugs
in the user's code (e.g. if the user used a wrong memory order constraint,
which caused a data race). Advice: Always
test your code with optimizations enabled.
atomic<T>
in shared memory only works correctly, if atomic<T>::is_lock_free() == true.