is assignment operator '=' atomic?
This code is not guaranteed to be thread-safe on Win32, since Win32 guarantees atomicity only for properly-aligned 4-byte and pointer-sized values. bool
is not guaranteed to be one of those types. (It is typically a 1-byte type.)
For those who demand an actual example of how this could fail:
Suppose that bool
is a 1-byte type. Suppose also that your is_true
variable happens to be stored adjacent to another bool
variable (let's call it other_bool
), so that both of them share the same 4-byte line. For concreteness, let's say that is_true
is at address 0x1000 and other_bool
is at address 0x1001. Suppose that both values are initially false
, and one thread decides to update is_true
at the same time another thread tries to update other_bool
. The following sequence of operations can occur:
- Thread 1 prepares to set
is_true
totrue
by loading the 4-byte value containingis_true
andother_bool
. Thread 1 reads 0x00000000. - Thread 2 prepares to set
other_bool
totrue
by loading the 4-byte value containingis_true
andother_bool
. Thread 2 reads 0x00000000. - Thread 1 updates the byte in the 4-byte value corresponding to
is_true
, producing 0x00000001. - Thread 2 updates the byte in the 4-byte value corresponding to
other_bool
, producing 0x00000100. - Thread 1 stores the updated value to memory.
is_true
is nowtrue
andother_bool
is nowfalse
. - Thread 2 stores the updated value to memory.
is_true
is nowfalse
andother_bool
is nowtrue
.
Observe that at the end this sequence, the update to is_true
was lost, because it was overwritten by thread 2, which captured an old value of is_true
.
It so happens that x86 is very forgiving of this type of error because it supports byte-granular updates and has a very tight memory model. Other Win32 processors are not as forgiving. RISC chips, for example, often do not support byte-granular updates, and even if they do, they usually have very weak memory models.
no, its not..... you need to use a locking primitive of some sort. Depending on platform, you can either use boost ones, or if going native windows, something like InterlockedCompareExchange.
In fact in your situation you might what to use some of the thread safe event mechanisims so you can 'signal' your other thread to start doing what you want.
On all modern processors, you can assume that reads and writes of naturally aligned native types are atomic. As long as the memory bus is at least as wide as the type being read or written, the CPU reads and writes these types in a single bus transaction, making it impossible for other threads to see them in a half-completed state. On x86 and x64 there, is no guarantee that reads and writes larger than eight bytes are atomic. This means that 16-byte reads and writes of streaming SIMD extension (SSE) registers, and string operations, might not be atomic.
Reads and writes of types that are not naturally aligned—for instance, writing DWORDs that cross four-byte boundaries—are not guaranteed to be atomic. The CPU may have to do these reads and writes as multiple bus transactions, which could allow another thread to modify or see the data in the middle of the read or write.