3

I have two threads: 'main' and 'worker', and one global variable bool isQuitRequested that will be used by the main thread to inform worker, when it's time to quit its while loop (something like this: while(isQuitRequested == false) { ... do some stuff ... })

Now, I'm a bit concerned... Do I need to use some kind of mutex protection for isQuitRequested, considering that only one thread (main) performs isQuitRequested = true operation, and the other (worker) just performs checking and nothing else?

I have read What could happen if two threads access the same bool variable at the same time?. I'ts something similar, but not the same situation...

Community
  • 1
  • 1
Gediminas
  • 1,830
  • 3
  • 27
  • 47

4 Answers4

4

You have not specified which language you are using and from the small code snippet that you posted it could be either C#, Java or C++. Here are some common solutions for this "pattern" for each of them:

C#:

volatile bool isQuitRequested;

Java:

volatile boolean isQuitRequested;

C++: volatile in C++ is not nearly as useful. Go with:

std::atomic<bool> isQuitRequested;
Tudor
  • 61,523
  • 12
  • 102
  • 142
  • Isn't "**volatile**" enough in situation like mine? ( http://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.80).aspx ) And regarding "**atomic**", are we talking here about "Boost.Atomic" ? ( http://www.chaoticmind.net/~hcb/projects/boost.atomic/ ) – Gediminas Feb 15 '12 at 12:05
  • The `volatile` **is** useful in C. Marking it `volatile` will force the compiler to generate the code that reads `isQuitRequested` from memory each time it's accessed (not cache in register). This won't cause memory fences and etc., but this is not needed in the described scenario. – valdo Feb 15 '12 at 12:09
  • `volatile` in C++ will only prevent the compiler from optimizing (caching), but not the CPU, which may perform reorders/caches of its own (although whether you really need it on x86 or not is debatable). In C#/Java it does both. That `atomic` I mentioned is actually `std::atomic`. I'll edit. – Tudor Feb 15 '12 at 12:37
3

This should be safe with a volatile bool, as long as you are not using any data in the consumer (which checks the bool) thread affected by the producer thread (which sets the bool to true), AND after your consumer thread finds that the bool has been set to true, it does not attempt to reuse/reset it as a way of communicating with the producer thread (as in the example you link).

This is because that case makes memory reordering a non-issue.

Michael Chinen
  • 17,737
  • 5
  • 33
  • 45
  • Your answer is the most exact IMHO. Using any kind of sync objects (including memory fences) is an overkill here. The only thing that is **really** needed is the `volatile` keyword – valdo Feb 15 '12 at 12:11
1

In Java you only need to mark that variable as volatile:

volatile boolean isQuitRequested;

Or use AtomicBoolean. Otherwise the change made by one thread might not be visible by other threads.

However in your case there is a built-in functionality: simply call interrupt() on a thread and handle it, see: How to stop a thread that is running forever without any use.

See also:

Community
  • 1
  • 1
Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
0

according to my experience on windows a global variable is usually enough if it is of one of the basic types char, short, int, long. If you want to do it the "correct way", the solution of @Tudor looks fine.