Consider the following scenario:
- There exists a globally accessible variable
F. - Thread
Arepeatedly assigns a random value toF(without any regard to the previous value ofF). - Thread
Bdoes the same thing as threadA(independent ofA). - Thread
Crepeatedly reads the value ofF(and say, prints it).
This is in C++ (Visual C++) on Windows on x64 architecture, multi-processor. F is of type bool and marked volatile, and none of the accesses are protected by any locks.
Question: Is there anything thread-unsafe about this scenario?
Assuming that the logical behavior of the code is valid, is there anything unsafe about the fact that multiple threads are reading and writing the values to the same location at the same time?
What guarantees can be made (across architectures, OSes, compilers) about the atomicity of reading from and writing to variables that are <= word-size on the platform? (I am assuming word-size is important…)
On a related note, what is an acceptible way of communicating between threads the state of completion of some operation (none of the threads are waiting for the operation to complete, they may just be interested in querying the state from time to time)?
It depends on your thread-safety requirements. You’ll always get a consistent value (that is, it is impossible that you get half the value of thread A’s write and the other half from thread B), but there is no guarantee that the value you’ll read is, in fact, the latest one that was logically written.
The problem here is the CPU cache that may or may not get flushed. When a thread writes to the memory, the value first goes to the cache, and eventually it gets written to memory. In the while, if other cores attempt to read the object from memory, they’ll get the old value.