In the previous C++ Multithreading article I presented you how to pass parameters between threads. Take a detail look on the output of that example once again:
In the first line of that output you can notice that output text from two threads is mixed. You are probably wondering why it happens?
It is because we are not protecting resources which are shared by two threads (in this example cout stream is shared in both threads) which causes multithreading's phenomenon called race condition.
Because threads switching and accessing to shared resources are managed by operating system we do not know when std::cout stream will be accessed by main thread and when it will be accessed by second thread. Therefore in the previous article I mentioned that output of the example can be little different on your computer than my output example.
What's more it is possible that this output will be different for few consecutive invoking of the example on the same machine. It is because of race condition access to std::cout between main thread and second thread.
In theory, race condition is any situation where output of some operation (ex. function return) depends on relative ordering of execution of some operations on two or more threads. It is one of the biggest problems during multithreading-based programming.
For better understanding race conditions take a look on another example below: Try to compile and invoke that example few times on your computer. What is a result? Are you suprised?
On my computer three invokings of that examples returned three different results: It is of course because of race condition. Let's analyse that example step by step to understand why race conditions occurs here.
In point I we are creating intValue variable which will be shared and increased in both threads in parallel.
Operation in point II should be known. We are creating new thread here. One news here is that we are pushing function object instead of normal function as thread function which will be invoked in parallel. One more interesting thing which you should notice in this instruction is additional pair of brackets around ThreadClass(). Those additional brackets have to be use in the situation where we are passing function object to thread creating function in order to avoid ambiguity with invoking function which takes one parameter (pointer to the function which takes no parameters and returns ThreadClass object) and returns std::thread type object rather than creating new thread. It is little complicated but rethink it and you should understand.
In point III and IIIa we are invoking loop which increases intValue variable in parallel (in main thread and in parallel thread because we passed it by reference). That sharing intValue in both threads causes race condition here which causes different outputs for another invoking of our application. Let's take a detailed look at it.
Remember that we are in multi-threaded environment where things happens in parallel. Two for loop (from two threads) works in parallel and we have intValue shared between threads. Because threads are managed by operating system we do not know when (after which instruction) operating of for loop from main thread is switched to operating second thread.
Now consider following situation. We have following statement:
intValue = intValue + 1
That statement consist of 3 steps in the background:
We got the problem. Can you see problem with race condition right now? We expected increment of intValue two times while it was applied only once in such situation!
As you can imagine that such situation can occur many many times while our loop has 1000000 steps. Of course it sometimes occurs and sometimes we have normal sequential invocation (depends how operating system switches threads). Therefore we receive other results when we invoke our application many times. I hope you got it.
Of course such ambiguous output cause by race conditions is undesirable and it is programmer's work to make it unambiguous. Some technique how to synchronize usage of shared resources between threads will be presented in next C++11 Multithreading article.
I encourage you to think and write some other examples when race conditions can occur and experiment with them for better understanding that very important phenomenon of multi-threading programming.
Code of this article you can find in our GitHub account here: https://github.com/xmementoit/CppAdventureExamples/tree/master/multithreading/raceConditions
In the first line of that output you can notice that output text from two threads is mixed. You are probably wondering why it happens?
It is because we are not protecting resources which are shared by two threads (in this example cout stream is shared in both threads) which causes multithreading's phenomenon called race condition.
Because threads switching and accessing to shared resources are managed by operating system we do not know when std::cout stream will be accessed by main thread and when it will be accessed by second thread. Therefore in the previous article I mentioned that output of the example can be little different on your computer than my output example.
What's more it is possible that this output will be different for few consecutive invoking of the example on the same machine. It is because of race condition access to std::cout between main thread and second thread.
In theory, race condition is any situation where output of some operation (ex. function return) depends on relative ordering of execution of some operations on two or more threads. It is one of the biggest problems during multithreading-based programming.
For better understanding race conditions take a look on another example below: Try to compile and invoke that example few times on your computer. What is a result? Are you suprised?
On my computer three invokings of that examples returned three different results: It is of course because of race condition. Let's analyse that example step by step to understand why race conditions occurs here.
In point I we are creating intValue variable which will be shared and increased in both threads in parallel.
Operation in point II should be known. We are creating new thread here. One news here is that we are pushing function object instead of normal function as thread function which will be invoked in parallel. One more interesting thing which you should notice in this instruction is additional pair of brackets around ThreadClass(). Those additional brackets have to be use in the situation where we are passing function object to thread creating function in order to avoid ambiguity with invoking function which takes one parameter (pointer to the function which takes no parameters and returns ThreadClass object) and returns std::thread type object rather than creating new thread. It is little complicated but rethink it and you should understand.
In point III and IIIa we are invoking loop which increases intValue variable in parallel (in main thread and in parallel thread because we passed it by reference). That sharing intValue in both threads causes race condition here which causes different outputs for another invoking of our application. Let's take a detailed look at it.
Remember that we are in multi-threaded environment where things happens in parallel. Two for loop (from two threads) works in parallel and we have intValue shared between threads. Because threads are managed by operating system we do not know when (after which instruction) operating of for loop from main thread is switched to operating second thread.
Now consider following situation. We have following statement:
intValue = intValue + 1
That statement consist of 3 steps in the background:
- read value of intValue and store it in temporary variable tmp
- increase value of tmp by 1
- write value of tmp to intValue
- Thread 1 reads value of intValueand stores it in tmp1 (tmp1 == 100)
- Thread 2 reads value of value (which is reference to value so basically it is the same variable as intValue) and stores it in tmp2 (tmp2 == 100)
- Thread 1 increase value of tmp1 by 1 (tmp1 == 101)
- Thread 2 increase value of tmp2 by 1 (tmp2 == 101)
- Thread 1 writes value of tmp1 into intValue (intValue == 101)
- Thread 2 writes value of tmp2 into value value (value == 101)
As you can imagine that such situation can occur many many times while our loop has 1000000 steps. Of course it sometimes occurs and sometimes we have normal sequential invocation (depends how operating system switches threads). Therefore we receive other results when we invoke our application many times. I hope you got it.
Of course such ambiguous output cause by race conditions is undesirable and it is programmer's work to make it unambiguous. Some technique how to synchronize usage of shared resources between threads will be presented in next C++11 Multithreading article.
I encourage you to think and write some other examples when race conditions can occur and experiment with them for better understanding that very important phenomenon of multi-threading programming.
Code of this article you can find in our GitHub account here: https://github.com/xmementoit/CppAdventureExamples/tree/master/multithreading/raceConditions
Comments
Post a Comment