Why is volatile not considered useful in multithreaded C or C++ programming?

by

The problem with volatile in a multithreaded context is that it doesn’t provide all the guarantees we need. It does have a few properties we need, but not all of them, so we can’t rely on volatile alone.

However, the primitives we’d have to use for the remaining properties also provide the ones that volatile does, so it is effectively unnecessary.

For thread-safe accesses to shared data, we need a guarantee that:

  • the read/write actually happens (that the compiler won’t just store the value in a register instead and defer updating main memory until much later)
  • that no reordering takes place. Assume that we use a volatile variable as a flag to indicate whether or not some data is ready to be read. In our code, we simply set the flag after preparing the data, so all looks fine. But what if the instructions are reordered so the flag is set first?

volatile does guarantee the first point. It also guarantees that no reordering occurs between different volatile reads/writes. All volatile memory accesses will occur in the order in which they’re specified. That is all we need for what volatile is intended for: manipulating I/O registers or memory-mapped hardware, but it doesn’t help us in multithreaded code where the volatile object is often only used to synchronize access to non-volatile data. Those accesses can still be reordered relative to the volatile ones.

The solution to preventing reordering is to use a memory barrier, which indicates both to the compiler and the CPU that no memory access may be reordered across this point. Placing such barriers around our volatile variable access ensures that even non-volatile accesses won’t be reordered across the volatile one, allowing us to write thread-safe code.

However, memory barriers also ensure that all pending reads/writes are executed when the barrier is reached, so it effectively gives us everything we need by itself, making volatile unnecessary. We can just remove the volatile qualifier entirely.

Since C++11, atomic variables (std::atomic<T>) give us all of the relevant guarantees.

More Related Contents:

  1. When to use volatile with multi threading?
  2. Why does volatile exist?
  3. Does the C++ volatile keyword introduce a memory fence?
  4. Is volatile bool for thread control considered wrong?
  5. Is ‘volatile’ needed in this multi-threaded C++ code?
  6. Why can templates only be implemented in the header file?
  7. When can I use a forward declaration?
  8. “std::endl” vs “\n”
  9. What is the difference between public, private, and protected inheritance in C++?
  10. What’s the difference between “STL” and “C++ Standard Library”?
  11. How do I remove code duplication between similar const and non-const member functions?
  12. Why is it wrong to use std::auto_ptr with standard containers?
  13. How should I write ISO C++ Standard conformant custom new and delete operators?
  14. Windows threading: _beginthread vs _beginthreadex vs CreateThread C++
  15. Passing object by reference to std::thread in C++11
  16. What C++ Smart Pointer Implementations are available?
  17. What is the purpose of std::launder?
  18. Why do we use volatile keyword? [duplicate]
  19. Why do I see strange values when I print uninitialized variables?
  20. gcc/g++: “No such file or directory”
  21. How to use std::async on a member function?
  22. Why do we actually need Private or Protected inheritance in C++?
  23. Acquire/release semantics with non-temporal stores on x64
  24. How to easily make std::cout thread-safe?
  25. What is different between join() and detach() for multi threading in C++?
  26. std::thread error (thread not member of std)
  27. Does std::mutex create a fence?
  28. ReleaseSemaphore does not release the semaphore
  29. GCC std::thread not found in namespace std
  30. Why does this simple std::thread example not work?

Leave a Comment