Question about thread safety

Question

The simple situation is here, If I have three threads and one for the window application, and I want them to stop working when the window application is closed, it is thread-safe if I use one global variable, so that three threads will stop, if only the global variable is true, otherwise continue your work? Does unstable help help in this situation? C ++.

Answer 1

If you only want to "read" from a shared variable from other threads, then this is normal in the situation you are describing.

Yes, volatile hint is required or the compiler can "optimize" this variable.

Waiting for threads to finish (i.e. join ) will also be good: in this way, any cleanup (by the application) that should happen will have a chance to be done.

Answer 2

Theoretically, volatile not enough. There are two layers of abstraction:

• between source code actions and valid opcodes;
• between what the kernel / processor sees and what other kernels / processors see.

The compiler can cache data in a register and reorder read and write. Using volatile , you instruct the compiler to produce codes of operations that read and write exactly in the order specified in the source code. But this only processes the first layer. A hardware system that controls communications between processor cores can also delay and change the reading and writing order.

It so happened that on x86 hardware, the cores allocate entries to the main memory quite quickly, while other cores are automatically notified that the memory has changed. So volatile is enough: it guarantees that the compiler will not play funky games with registers, and the memory system is kind enough to process things from this point. Note, however, that this is not true for all systems (I think that at least some Sparc systems could slow down the distribution of recordings for arbitrary delays - maybe hours), and I read in one of AMD's manuals that AMD clearly reserves eligible spread faster are recorded in some future processors.

Thus, a clean solution is to use a mutex ( pthread_mutex_lock() on Unix, EnterCriticalSection() on Windows) when accessing your global variable (both for reading and writing). Mutex primitives include a special operation known as a memory barrier that resembles volatile like steroids (it acts like volatile for both layers of abstraction).

Answer 3

No, this is dangerous due to memory visibility issues. In multiprocessor mode, writing to memory on one processor does not mean that the other processor will immediately see this change. In addition, without the use of mutexes, it is possible that quite a long time has passed before the change will be distributed to other processors.

Answer 4

Yes, this is a common technique.

But you must also wait for all child threads to complete before the main () thread exits.
In most thread implementations, if the main thread exits main (), all current child threads are currently repeating (see the documentation for threads for details), preventing their stacks from being spun correctly. Thus, all the pleasant benefits of RAII will be lost.

So, set a global variable, but then wait (most streaming systems have a connection method that allows you to wait (for threads not in use) to die) so that all children exit cleanly before allowing main () to exit.

Answer 5

This is safe until the moment you change the value of a variable to close threads. At this point, 1) you need to synchronize access, and 2) you need to do something (sorry volatile is not enough) to ensure that the new value is correctly propagated to other threads.

The first part is pretty simple. The latter is much more complicated - to such an extent that you will almost certainly need some kind of mechanism supported by the library or OS.