Does the C++ 11 standard guarantees that std::atom

Question

I'm at a junction, I'm trying to pick one between mutex-lock-based data structure and lock-free ( and possibly wait-free ) data structure.

While digging a little deeper I found no word about the fact that the C++ 11 standard is supporting atomic operations for atomic types, not even for width-based integrals like atomic_uint32_t . In other words it's not just the std::atomic<> interface that is not granted to be really atomic, the only thing that looks like it's granted to be atomic in the whole standard library is std::atomic_flag .

Is this true or I'm missing something ? What is the reason for that ? I mean the standard calls "atomic" something that is clearly not atomic at all and it's something that is even allowed to use mutexes or blocking calls under the hood.

Answer 1

If by atomic you mean, using hardware support without locks, then yes, the standard doesn't give you a guarantee for that. Why? Well, because different architectures support different kind of hardware atomicity. std::atomic<> has the handy is_lock_free() method which can be used to check wether the given object is actually lock free, or uses a lock internally to guarantee atomic operations. You can use that and check on your target hardware wether it would be lock free or not, and then decide what data structure to go for.

However, that being said, if the target architecture has hardware support for atomic operations for the fixed width integrals you are interested in, and you didn't obtain your copy of the standard library from the the shady software shop in the ghetto, it's probably going to use the hardware instead of a full blown lock.

Answer 2

The C++ standard makes no guarantee that std::atomic<T> operations are atomic. However, you can use std::atomic<T>::is_lock_free() to find out if the operation of std::atomic<T> is lock free 29.6.5 [atomics.types.operations.req] paragraph 7:

Returns: True if the object’s operations are lock-free, false otherwise.

If it is not lock-free it will still do the required synchronization but it uses some lock to do so.