Printable View
I am working in VS2015 with C++11.
I have two threads going, and one is adding data to a queue. I have another function setting a flag of when i want to send all the data over. This variable is only used in these two threads.
Do I need to add any locks around this flag between the two threads? Would I be better off using an atomic?
Unless the flag is atomic, the behavior is undefined.
It's not included in your description, but you also have to ensure proper synchronization when the data is transferred, i.e. a critical section. When one threads adds data, you need to lock. When one thread reads, you need to lock. A flag usually is not sufficient to ensure mutual exclusion.
I am using a mutex lock on the data I am using.
Here is my thought on the flag. If one thread is only reading it and the other is only going to make a decision when it is true, is a lock still necessary? In other scenarios I can see a lock being 100% needed, but I'm curious about this case.
But, I will change my data type to be an atomic regardless.
Yes, if two or more threads access the same variable, then you must make it atomic or use locks around the variable.
The reason has to do with cache consistency on the processor level.
Since this is VS2015, you have the option of using volatile on the flag (defaults to /volatile:ms), but this implementation of volatile is Microsoft specific. There's a note near the end of that web page: "When it relies on the enhanced guarantee that's provided when the /volatile:ms compiler option is used, the code is non-portable."
volatile (C++)
The main issue is potential reordering of read / write operations within the compiler or processor that don't follow the order of the written software. For example, with no memory fence, when the thread that adds data to the queue, then sets the common flag, it's possible for some the queue updates to occur after the flag is set. Using a memory fence with memory order release semantics means that both the compiler and processor will complete all writes coded before the atomic write is performed. Using a memory fence with memory order acquire semantics, means that the atomic read will complete before any any reads coded after the atomic read are performed.Quote:
Originally Posted by CodeSlapper
Almost all multi-core processors and multi-processor motherboards guarantee cache coherency. The issue is potential out of order read / writes due to compiler or processor optimization.Quote:
Originally Posted by Elysia
I use the term "cache coherency" as a universal umbrella for all issues concerning sharing data between threads, i.e. thread synchronization. It includes all the things like instruction reordering by compiler and hardware, guaranteeing that data is not cached in registers, etc.
OK, but you should clarify your usage of the term versus the common usage:Quote:
Originally Posted by Elysia
Cache coherence - Wikipedia
Cache memory - Wikipedia
It has to do with more than that. Even before the processor comes into play, the compiler is able to make optimizations based on the assumption that is no concurrent access between threads without synchronization.Quote:
Originally Posted by Elysia
For example, if you have a loop that reads repeatedly from a variable, aka a spin lock, that read must be atomic or else the compiler may optimize it into a single read.
Any unsynchronized concurrent access is undefined behavior, and which means the compiler is allowed to assume that it can never happen, and may optimize based on that fact.
Then just call it a data race.Quote:
Originally Posted by Elysia