Concurrency: Atomic and Volatile in the C 11 Memory Model

When multiple threads concurrently access a shared global variable, the threads might write to and read from the variable with different copies cached in different processor cores. It is possible for one thread to read a stale value from its cache due to the potential discrepancy between the values stored in the different caches.

However, the C 11 standard provides the std::atomic library for atomic operations, ensuring that the latest value is read from the other cache. This is achieved through strong memory ordering, which guarantees that changes made by one thread are visible to other threads in a consistent order.

On the other hand, the volatile keyword simply indicates that a variable should not be optimized by the compiler, but it does not provide any guarantees of atomic access. It is designed primarily for scenarios such as memory-mapped I/O or signal handling.

In the context of shared variables between threads, such as the following:

std::atomic ai;

The behavior of volatile and atomic types will differ significantly. volatile does not guarantee atomic access, and its use in combination with std::atomic is redundant. If the hardware platform specifies otherwise, volatile may have no bearing on atomic access or memory ordering between threads.

On the other hand, the std::atomic type provides memory ordering through various options such as std::memory_order_seq_cst, which enforces a single total order for all atomic operations across all variables. This ensures that the visibility and ordering constraints are maintained, and threads will not observe stale values in a strictly defined order.

Additionally, using read-modify-write operations like exchange(), compare_exchange_strong(), and fetch_add() guarantees access to the latest value. By executing these operations within the same thread context, threads will observe the updated values in the correct order, avoiding inconsistencies.

Working with atomic operations requires careful consideration and understanding. It is advisable to thoroughly research background material and existing code to effectively implement atomicoperations in production code. In many cases, locks can provide a viable alternative when the challenges of atomic operations are not necessary.