WIN32 two thread synchronization classes for C + + (top)

Thread synchronization is the core of multithreaded programming, and its purpose is to correctly handle various problems of multithreading concurrency, such as thread waiting, mutual exclusion when multiple threads access the same data, deadlock-proof, etc. WIN32 provides a variety of kernel objects and tools for thread synchronization, such as mutexes, semaphores, events, critical areas, and so on. The difference is that the mutex, semaphores, events are Windows kernel objects, when the program to control these objects automatically converted to the nuclear mentality, and the critical area itself is not a kernel object, it is working in the user state. We know that the transition from user state to nuclear mentality is to take time, so if you can solve the problem in user state, you can not bother the core state.

Here I want to say is two kinds of multithreaded synchronization classes for C + +, through the use of these two types can be easily implemented on the variable or code section of the lock control, thus preventing multithreading on variable incorrect operation.

The so-called lock, which means that we need to get permission to continue before we have access to a key variable, and wait only if we don't get permission. A key variable has a lock, a thread must first get this lock (actually called the key may be more image) to access the variable, and when a variable holds this lock, the other thread can not be repeated to get it, only the lock-holding thread to return the lock after the other thread can get it. This is done in order to prevent a thread from reading an object while the other thread modifies it, or two threads modify a variable at the same time, for example:

// 全局：
struct MyStruct ... { int a, b; } ;
MyStruct s;
// 线程1：
int a = s.a;
int b = s.b;
// 线程2：
s.a ++ ;
s.b -- ;

If the actual order of execution is the order of the written above, there is nothing, but if thread 2 's execution interrupts thread 1, it becomes the following order:

int a = s.a; //线程1
s.a++; //线程2
s.b++; //线程2
int b = s.b; //线程1

Then thread 1 reads a and B and there is a problem, because a is read before the modification, and B is read after the modification, so that the incomplete data is read, which can have unpredictable consequences for the program. God knows what the two-way scheduling sequence is. To prevent this from happening, we need to lock the variable s, that is, when the thread 1 gets the lock can be assured access to S, then if the thread 2 to modify S, only the same thread 1 access to complete the lock release can be, so that the two-thread cross access variable will not appear.