Dangers of simultaneous write and read of a boolean in a simple situation

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.

Answer 2

The problem you might get is that we don't know how long it takes for the reader thread to see the changed value. If they are on different CPUs, with separate caches, there are no guarantees unless you use a memory barrier to synchronize the caches.

On an x86 this is handled automatically by the hardware protocol, but not on some other systems.

Answer 3

Do I need to use some synchronization mechanism(like mutexes) to protect b?

If you don't, you have a data race. Programs with data races have undefined behaviour. The answer to this question is the same as the answer to the question "Do you want your program to have well-defined behaviour?"

What can happen if I don't?

Theoretically, anything can happen. That's what undefined behaviour means. The most likely bad thing that can happen is that the "second thread" may never see a true value.

The compiler can assume that a program has no data races (if it has the behaviour is not defined by the standard, so behaving as if it didn't is fine). Since the second thread only ever reads from a variable that has the value false, and there's no synchronization that affects those reads, the logical conclusion is that the value never changes, and thus the loop is infinite. (and some infinite loops have undefined behaviour in C++11!)

Answer 4

Here are a few alternative solutions:

1. Use a Mutex, details have been covered in the other answers above.

2. Consider using a read/write lock which will manage/protect simultaneous reads and writes. The pthread lib provides an implementation: pthread_rwlock_t

3. Depending on what your application is doing, consider using a condition variable (pthread lib impl: pthread_cond_t). This is effectively a signal from one thread to another, which could allow you to remove your while loop and bool checking.

Answer 5

Making the boolean volatile will suffice (on x86 architecture), no mutex needed:

volatile bool b;