ABA

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

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.

An Analogy

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?

1. You look at the traffic light and it is red (A).

2. Because you are bored, you begin to check the news on your smartphone and forget the time.

3. 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:

1. Thread 1 reads the variable var with value A.
2. Thread 1 is preempted and thread 2 runs.
3. Thread 2 changes the variable var from A to B to A.
4. Thread 1 continues to run and checks the value of variable var and gets A. Because of the value A, thread 1 proceeds.

Often that is not a problem and you can simply ignore it.

Non-critical ABA

The functions compare_exchange_strong and 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 mult.