But the C or C++ standard does not guarantee that the value read will be either the new or the old value. On a machine that writes a value bit for bit, for example, the reading thread could see a combination of old and new bits.jwes wrote:I only write to this variable from one thread and do not care if it is read wrong once (as long as it is either the old value or the new value). I believe that is enough. If it is not, I hope someone will explain it to me.
The compiler might also be able to figure out that the variable is only read by a thread, so that that thread can "safely" cache its value in a register or a local variable.
This is why according to the C11 and C++11 standards reading a non-atomic value that may simultaneously be written by another thread gives undefined behaviour. (Earlier standards do not know about threads, so by definition guarantee nothing about threading behaviour.)
If you make the variable atomic and access it with relaxed memory ordering, all is fine. If accesses of the variable by the underlying machine architecture is atomic, this should not cause any overhead. The compiler is still allowed to temporarily cache the value of an atomic variable (so if your code accesses it a couple of times in a row the compiler may assume that all accesses return the same value and keep that value temporarily around in a register) but it will not cache the value indefinitely (so the code is guaranteed to eventually see a write by another thread).
Or you can just leave things as they are and accept that your code makes more assumptions about the machine architecture and the compiler than the C and C++ standards guarantee. This could bite you in the long run, but that may be acceptable to you.