Programming concurrent applications are inherently complicated. This still holds true if you use C++11 and C++14 features, and that is before I mention the memory model.
ABA means you read a value twice and it returns the same value A each time. Therefore, you conclude that nothing changed in between, but you missed the fact that the value was updated to B somewhere in between.
Let me first use a simple scenario to introduce the problem.
The scenario consists of you sitting in a car and waiting for the traffic light to become green. Green stands for B in our case, and red stands for A. What’s happening?
You look at the traffic light and it is red (A).
Because you are bored, you begin to check the news on your smartphone and forget the time.
You look once more at the traffic light. Damn, it is still red (A).
Of course, the traffic light became green (B) between your two checks. Therefore, what seems to be one red phase was actually a full cycle.
What does this mean for threads (processes)? Here is a more formal explanation:
- Thread 1 reads the variable
varwith value A.
- Thread 1 is preempted and thread 2 runs.
- Thread 2 changes the variable
varfrom A to B to A.
- Thread 1 continues to run and checks the value of variable
varand gets A. Because of the value
A, thread 1 proceeds.
Often that is not a problem and you can simply ignore it.
compare_exchange_weak suffer the ABA problem that can be observed in the
fetch_mult (line 7). Here, it is non-critical;
fetch_mult multiplies a
std::atomic<T>& shared by