By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,743 Members | 1,058 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,743 IT Pros & Developers. It's quick & easy.

Boolean variable thread safety in C++

P: 3
I wanted to know whether or not one should expect that the assignment and reading of boolean values (the type bool in c++) is thread safe.

I am using the latest release of pthreads on windows xp (Pthreads-w32 release 2.8.0) and the threading seems to work with MingGW GCC 3.4.5.

Setting and checking boolean variables seems to me as a useful approach to check whether or not a detached thread is done.

But how "atomic" is an assignment/reading of a bool?

Are these lines thread safe:
Expand|Select|Wrap|Line Numbers
  1. bool_var = true;
Expand|Select|Wrap|Line Numbers
  1. bool_var == true;
..or is it possible that the OS could make a context switching in the middle of the assignment? Or are all native-type assignments atomic in nature? I guess it depends on the compiler and the code it produces?

And yes, I am new at multi-threaded programming. Especially in native programming like C/C++.

Regards, Intel4004
May 20 '07 #1
Share this Question
Share on Google+
2 Replies


weaknessforcats
Expert Mod 5K+
P: 9,197
No, those lines are maybe not thread safe.

If this code appears on more than one thread, It could happen that bool_var is sucked into the processor and set to false but before the variable is returned to memory, a context switch could occur where the bool_var is set to true by another thread. Then this thread thaws and the false is put in memory where the other thread expected true. That is a race condition and a crash is not long in coming.

C++ is not thread safe. You need critical sections and/or mutexes around processing that is exposed to more than one thread.

If bool_var appears only in one thread, then bool_var = false is thread safe becuse there are no other threads that use it.

Of course, you remember that static variables, global variables, and variables in namespaces that are visibile to more than one thread are also not thread safe.
May 20 '07 #2

P: 3
No, those lines are maybe not thread safe.

If this code appears on more than one thread, It could happen that bool_var is sucked into the processor and set to false but before the variable is returned to memory, a context switch could occur where the bool_var is set to true by another thread. Then this thread thaws and the false is put in memory where the other thread expected true. That is a race condition and a crash is not long in coming.

C++ is not thread safe. You need critical sections and/or mutexes around processing that is exposed to more than one thread.

If bool_var appears only in one thread, then bool_var = false is thread safe becuse there are no other threads that use it.

Of course, you remember that static variables, global variables, and variables in namespaces that are visibile to more than one thread are also not thread safe.
Ok - thanks for quick reply.

I was experiencing problems with my pthreads and also with pthread-based wxThread objects from the wxwidgets framework, but i believe it was something else now.

But let's say I have an object JOB with a public non-static method JOB::do() which calls some heavy code (processing a big file or similar). I have another object APP. In object APP i create a detached thread and implement the code of the thread in APP::entry(). APP owns an instance of JOB (on the heap).

Expand|Select|Wrap|Line Numbers
  1. JOB::do()
  2. {
  3.    m_bool_doing = true;
  4.    //begin process taking long time
  5.    m_bool_doing = false;
  6. }
  7.  
  8. APP::entry()
  9. {
  10.    m_bool_threadBusy = true;
  11.    m_job->do();
  12.    m_bool_threadBusy = false;
  13. }
  14.  
This is possible with wxwidgets - but this is just the general idea. I'll find a wxwidgets forum for other questions :)

So how is it with calling methods on an object of JOB while another method is running in the thread of APP? Let's say that after i create the detached thread in APP i call other methods on APP; perhaps some form of progress request (the code in JOB::do() could update some internal variables telling about its internal progress).

Perhaps I am babbling - perhaps I will create a new thread about this problem.

regards, Intel4004
May 20 '07 #3

Post your reply

Sign in to post your reply or Sign up for a free account.