C++11 multithreaded Programming (iv): data sharing and competitive conditions __ programming

In a multithreaded environment, data sharing between threads is simple, but in a program this simple data sharing can cause problems, one of which is competitive conditions.

What is a competitive condition?
Race conditions are a bug that occurs in a multithreaded application
When two or more threads perform a set of operations in parallel, accessing the same memory location, one or more of them will modify the data in the memory location, which may result in some unexpected results, which is the competitive condition.

Competitive conditions are often harder to find and reproduce, because they do not always occur, and they occur only when two or more threads perform an unexpected result in the relative order of the operations, by example:

Class Wallet {
  int mmoney;
 Public:
  Wallet (): Mmoney (0) {}
  int Getmoney () {return mmoney;}
  void Addmoney {for
    (int i = 0; i < money; i++) {
      mmoney++;}}}
; 

Create 5 threads that share an object of class wallet, and add 1000 internal funds in parallel using the Addmoney () member function. So, if the money in the original wallet is 0, then the money in the wallet should be 5000 after all the threads have been executed.
However, because all threads modify shared data at the same time, in some cases the money in the wallet may be much less than 5000.
The test is as follows:

#include <iostream>
#include <thread>
#include <algorithm>  

class Wallet {  
  int Mmoney;  
 Public:  
  Wallet (): Mmoney (0) {}  
  int Getmoney () {return mmoney;}  
  void Addmoney {for  
    (int i = 0; i < money; i++) {  
      mmoney++;}}}  
;  

int Testmultithreadwallet () {  
  Wallet walletobject;  
  std::vector<std::thread> Threads;  
  for (int i = 0; i < 5; i++) {  
    threads.push_back (Std::thread (&wallet::addmoney, &walletobject, 1000)); 
  } for  
  
  (int i = 0; i < 5; i++) {  
    threads.at (i). join ();  
  
  return Walletobject.getmoney ();  
}  
  
int main () {  
  int val = 0;  
  for (int k = 0; k < 1000; k++) {  
    if (val = = Testmultithreadwallet ())!= 5000) {  
      std::cout << ' Error at Count = "<< k <<" money in Wallet = "<< val << std::endl;  
    }"  
  
  return 0;  
}  

Since the member function Addmoney () of the same Wallet class object has been executed 5 times, the money is expected to be 50000, but because the Addmoney () member function executes in parallel, in some cases the Mmoney may be much less than 5000
Output:

Error at count = 971-  Wallet = 4568
Error at count = 971 $ in  Wallet = 4568
Error at count = 9  Wallet = 4260
Error at count = 972-  Wallet = 4260
error at count = 973  money in Wa Llet = 4976
Error at count = 973 to  Wallet = 4976

the reason for this phenomenon:
Each thread adds the same member variable "Mmoney" in parallel, seemingly a line, but this "nmoney++" is actually converted to 3 machine commands:
• Load "Mmoney" variables in register
• Increase the value of the Register
• Update the "Mmoney" variable with the value of register
Now, suppose that in a particular case, the above command executes the following procedure:

Thread 1:	Thread 2:
Loading "Mmoney" variables in registers
	Loading "Mmoney" variables in registers
Increase the value of a register
	Increase the value of a register
Update the "Mmoney" variable with the value in the Register
	Update the "Mmoney" variable with the value in the Register

In this case, an increment is ignored, because instead of adding the Mmoney variable two times, instead of adding a different register, the value of the "Mmoney" variable is overwritten.

Suppose that before this happens, the value of the Mmoney is 46. As shown in the above illustration, it increases 2 times, so the expected result is 48. However, due to the competitive conditions in the above situation, the Mmoney final value is only 47
This is called the competition condition.

How to fix this competitive condition
To solve this problem, we need to use the lock mechanism, where each thread needs to acquire a lock before modifying or reading the shared data and releasing the lock after the operation completes.

The next section continues to discuss how to operate