No type in C++ is "atomic by nature" unless it is an std::atomic*
-something. That's because the standard says so.
In practice, the actual hardware instructions that are emitted to manipulate an std::atomic<bool>
may (or may not) be the same as those for an ordinary bool
, but being atomic is a larger concept with wider ramifications (e.g. restrictions on compiler re-ordering). Furthermore, some operations (like negation) are overloaded on the atomic operation to create a distinctly different instruction on the hardware than the native, non-atomic read-modify-write sequence of a non-atomic variable.
Remember about memory barriers. Although it may be impossible to change bool
partially, it is possible that multiprocessor system has this variable in multiple copies and one thread can see old value even after another thread has changed it to new. Atomic introduces memory barrier, so it becomes impossible.
C++'s atomic types deal with three potential problems. First, a read or write can be torn by a task switch if the operation requires more than one bus operation (and that can happen to a bool
, depending on how it's implemented). Second, a read or write may affect only the cache associated with the processor that's doing the operation, and other processors may have a different value in their cache. Third, the compiler can rearrange the order of operations if they don't affect the result (the constraints are a bit more complicated, but that's sufficient for now).
You can deal with each of these three problems on your own by making assumptions about how the types you are using are implemented, by explicitly flushing caches, and by using compiler-specific options to prevent reordering (and, no, volatile
doesn't do this unless your compiler documentation says it does).
But why go through all that? atomic
takes care of it for you, and probably does a better job than you can do on your own.
Consider a compare and exchange operation:
bool a = ...;
bool b = ...;
if (a)
swap(a,b);
After we read a, we get true, another thread could come along and set a false, we then swap (a,b), so after exit b is false, even though the swap was made.
Using std::atomic::compare_exchange
we can do the entire if/swap logic atomically such that the other thread could not set a to false in between the if and the swap (without locking). In such a circumstance if the swap was made than b must be false on exit.
This is just one example of an atomic operation that applies to a two value type such as bool.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With