Question

I’ve read some similar questions but the situations described there are bit more complicated.

I have a bool b initialized as false in the heap and two threads. I do understand that operations with bools are not atomic, but please read the question till the end.

First thread can set b = true only once and doesn’t do anything else with it.
Second thread checks b in a loop and if it’s true does some actions.

Do I need to use some synchronization mechanism(like mutexes) to protect b?
What can happen if I don’t? With ints I can obviously get arbitrary values when I read and write in the same time. But with bools there are just true and false and I don’t mind to once get false instead of true. Is it a potential SIGSEGV?

Answer 1

Data races result in undefined behavior. As far as the standard is concerned, a conforming implementation is permitted to segfault.

In practice the main danger is that without synchronization, the compiler will observe enough of the code in the reader loop to judge that b “never changes”, and optimize out all but the first read of the value. It can do this because if it observes that there is no synchronization in the loop, then it knows that any write to the value would be a data race. The optimizer is permitted to assume that your program does not provoke undefined behavior, so it is permitted to assume that there are no writes from other threads.

Marking b as volatile will prevent this particular optimization in practice, but even on volatile objects data races are undefined behavior. Calling into code that the optimizer “can’t see” will also prevent the optimization in practice, since it doesn’t know whether that code modifies b. Of course with link-time/whole-program optimization there is less that the optimizer can’t see, than with compile-time-only optimization.

Anyway, preventing the optimization from being made in software doesn’t prevent the equivalent thing happening in hardware on a system with non-coherent caches (at least, so I claim: other people argue that this is not correct, and that volatile accesses are required to read/write through caches. Some implementations do behave that way). If you’re asking about what the standard says then it doesn’t really matter whether or not the hardware shows you a stale cache indefinitely, since behavior remains undefined and so the implementation can break your code regardless of whether this particular optimization is the thing that breaks it.