Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: Is it necessary to synchronize simple variable for threads?


This question is answered. Helpful answers available: 0. Correct answers available: 1.


Permlink Replies: 8 - Last Post: Dec 15, 2016 3:14 AM Last Post By: Martin van der ...
CN Liou

Posts: 8
Registered: 7/18/03
Is it necessary to synchronize simple variable for threads?  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 14, 2016 7:35 AM
Hi!

Imagine that the main thread holds a variable bool StopNow. This main thread launches several worker threads, each of which loops and reads this variable StopNow in order to determine if themselves should break their loops and exit immediately. When the program wants to terminate, the main thread simply sets variable StopNow to true and then waits for all worker threads to exit and then itself terminates.

I can understand that complex data structure like STL container must be synchronized by mechanisms such as TCriticalSection to serialize the writing to/reading from these kind of data structure by multiple threads. However, although I do not have the source code of TThread, I guess its member variable Terminated is not protected at all, meaning that

1. main thread can directly assign true or false to Terminated without first blocking the thread that owns this member variable.

2. the thread owning this member variable can read it any time it wants without considering whether or not this variable is being simultaneously updated by main thread.

Therefore, I am thinking that synchronization mechanism needs not to be implemented to protect variables of simple data types (POD?) such as int, bool, char, double , etc. Am I correct?

Thank you for the enlightenment in advance!

CN
Alex Belo

Posts: 626
Registered: 10/8/06
Re: Is it necessary to synchronize simple variable for threads?  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 14, 2016 8:21 AM   in response to: CN Liou in response to: CN Liou
CN Liou wrote:

Therefore, I am thinking that synchronization mechanism needs not to
be implemented to protect variables of simple data types (POD?) such
as int, bool, char, double , etc. Am I correct?

It depends on CPU type; I think you ask about x86.

Intel x86 guarantees atomic access to single memory cell of properly
aligned integer data types (byte, word16, int32) and double/float
automatically on hardware level.

Googling returns these articles, for example:

Atomic vs. Non-Atomic Operations
http://preshing.com/20130618/atomic-vs-non-atomic-operations/

Is Updating double operation atomic
http://stackoverflow.com/questions/1292786/is-updating-double-operation-atomic

All other data (arbitrary POD stricture, for example) read/write access
is not thread-safe.

In your case (boolean flag) there is no problem.

1. main thread can directly assign true or false to Terminated without
first blocking the thread that owns this member variable.

Yes, no problem.

2. the thread owning this member variable can read it any time it
wants without considering whether or not this variable is being
simultaneously updated by main thread.

Yes, no problem too.

--
Alex
CN Liou

Posts: 8
Registered: 7/18/03
Re: Is it necessary to synchronize simple variable for threads?  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 14, 2016 10:25 PM   in response to: Alex Belo in response to: Alex Belo

If I knew the terminology atomic operation earlier, I would not have raised this question here. Instead, I would have searched the web using this key words. Thanks for pointing me to the new world!

By the way, starting from the first link you provided, I found [Mintomic library|http://mintomic.github.io] worth study for those who rely on C++ mutext, locks, threads, smart pointers, etc. but like myself still use C++Builder 6 which

- does not support C++11
- is not supported by libraries such as newer versions of Boost
Sean Hoffman

Posts: 126
Registered: 3/28/99
Re: Is it necessary to synchronize simple variable for threads?
Helpful
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 14, 2016 8:25 AM   in response to: CN Liou in response to: CN Liou
To be safe, please insure that you declare StopNow using the c++ volatile keyword.
CN Liou

Posts: 8
Registered: 7/18/03
Re: Is it necessary to synchronize simple variable for threads?  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 14, 2016 10:26 PM   in response to: Sean Hoffman in response to: Sean Hoffman
Sean Hoffman wrote:
To be safe, please insure that you declare StopNow using the c++ volatile keyword.

I will to it. Thanks!
Andrew Law

Posts: 74
Registered: 11/6/02
Re: Is it necessary to synchronize simple variable for threads?
Helpful
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 14, 2016 8:33 AM   in response to: CN Liou in response to: CN Liou
CN Liou wrote:
Hi!

Imagine that the main thread holds a variable bool StopNow. This main thread launches several worker threads, each of which loops and reads this variable StopNow in order to determine if themselves should break their loops and exit immediately. When the program wants to terminate, the main thread simply sets variable StopNow to true and then waits for all worker threads to exit and then itself terminates.

I can understand that complex data structure like STL container must be synchronized by mechanisms such as TCriticalSection to serialize the writing to/reading from these kind of data structure by multiple threads. However, although I do not have the source code of TThread, I guess its member variable Terminated is not protected at all, meaning that

1. main thread can directly assign true or false to Terminated without first blocking the thread that owns this member variable.

2. the thread owning this member variable can read it any time it wants without considering whether or not this variable is being simultaneously updated by main thread.

Therefore, I am thinking that synchronization mechanism needs not to be implemented to protect variables of simple data types (POD?) such as int, bool, char, double , etc. Am I correct?

Thank you for the enlightenment in advance!

CN

I have always understood that even "primitive" operations like assignments or tests on a bool variable may not be atomic, and that there it is therefore necessary to protect such variables behind a mutex or a TCriticalSection. Here, "atomic" means "guaranteed not to be interrupted part-way through".

One possible explanation: a single line of code in your editor may be compiled into more than one instruction in machine code, so that something that looks atomic in the source code may not be atomic in machine code. Why does this matter? Well, it's just possible that a context switch between threads might occur between adjacent machine code instructions that implement a one line get or set operation, such that at the time of the context switch, it is not clear whether or not the get or set operation has taken place. Results would be undefined.

Any modern processor these days is likely to have multiple physical cores, making it even less safe than discussed above to assume that simple variables like bools could be accessed in a thread-safe way without mutex protection. And a server with multiple CPU chips (e.g. dual Xeon server) makes this even more of a problem.

You may get away with it for months without observing an error, but that does not mean that it is safe. Using a mutex like TCriticalSection carefully is very light-weight, and is better overall than having your program blow up months down the line for no obvious reason at the time, and with unpredictable results.

UPDATE: While I was writing the text above, others have also posted, reaching a different conclusion. Please forgive me for pursuing this, I have no wish to start a flame war, but am genuinely curious as to whether it truly is safe.

For example, please consider this discussion, in particular the accepted answer from Mats Petersson, which suggests that it is not guaranteed that, after your setter function has run, all subsequent getter requests will get the "right" answer. This may be extremely important to the correct functioning of your program...
http://stackoverflow.com/questions/14624776/can-a-bool-read-write-operation-be-not-atomic-on-x86

Edited by: Andrew Law on Dec 14, 2016 8:35 AM
CN Liou

Posts: 8
Registered: 7/18/03
Re: Is it necessary to synchronize simple variable for threads?  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 14, 2016 11:02 PM   in response to: Andrew Law in response to: Andrew Law
Thanks for so detailed explanation!

Locks make my code uglier (more difficult to understand) and more dead lock prone although as you pointed out - the footprint of locks is lightweight.

In my use case (and I guess TThread::Terminated, and TThread::Terminate(), too), even if operations on bool variable is not atomic, the worst side effect of "tearing" or "data race" is, I think, that the reading threads can miss true value once and as a result waste one more loop. They will get true value at next iteration and ultimately exit. Having read the materials given in this thread, I will remove the existing lock protecting bool variable from my code as I anticipate my program will not crash even without the lock.

Best Regards,
Jan Dijkstra

Posts: 206
Registered: 11/4/99
Re: Is it necessary to synchronize simple variable for threads?  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 14, 2016 11:49 PM   in response to: CN Liou in response to: CN Liou
CN Liou wrote:
Thanks for so detailed explanation!

Locks make my code uglier (more difficult to understand) and more dead lock prone although as you pointed out - the footprint of locks is lightweight.

In my use case (and I guess TThread::Terminated, and TThread::Terminate(), too), even if operations on bool variable is not atomic, the worst side effect of "tearing" or "data race" is, I think, that the reading threads can miss true value once and as a result waste one more loop. They will get true value at next iteration and ultimately exit. Having read the materials given in this thread, I will remove the existing lock protecting bool variable from my code as I anticipate my program will not crash even without the lock.

Best Regards,

Given that the VCL/RTL code for the Terminated boolean also does not use locking, you're probably correct in this assumption ;)
Martin van der ...

Posts: 57
Registered: 7/14/02
Re: Is it necessary to synchronize simple variable for threads?  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 15, 2016 3:14 AM   in response to: CN Liou in response to: CN Liou
As a general rule, always synchronize.

There's not only the matter of accessing partially modified values (which WOULD be difficult with a boolean), but both the compiler and the CPU may re-order instructions to improve execution performance. Synchronization instructions tell them not to do that.
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02