The second multi-threaded third atomic Operations Interlocked series function describes the role of atomic operations in multiple processes, now a complex point. This problem involves thread synchronization and mutual exclusion, is a very representative multi-threaded synchronization problem, if the problem can be clear, then the multi-threaded synchronization has laid a good foundation.
Program Description:
The main thread initiates 10 child threads and passes the variable address representing the subroutine number as a parameter to the child thread. The child thread receives the parameter, sleep (0), the global variable + +, and the global variable.
Requirements:
1. The line program number that the child thread outputs cannot be duplicated.
2. The output of the global variable must be incremented.
Here's a simple one:
Analysis of the problem of the study point, the main points of study are two:
1. The main thread creates a sub-thread and passes in a pointer to the address of the variable as a parameter, because the thread starts to take a certain amount of time, so before the child thread accesses and saves the data according to the pointer, the main line thread executes waits for the child thread to save the parameter and starts the next thread. This involves synchronization between the main thread and the child thread .
2. There are mutually exclusive changes and output global variables between the child threads. Requires that the output of global variables be incremented. This involves mutual exclusion between sub-threads .
The basic framework of this program is listed below, which can be modified and validated based on this code.
[CPP]View PlainCopy
- Classic thread Synchronization Mutex problem
- #include <stdio.h>
- #include <process.h>
- #include <windows.h>
- Long G_nnum; //Global resource
- unsigned int __stdcall fun (void *ppm); //thread function
- const int thread_num = 10; //number of child threads
- int main ()
- {
- G_nnum = 0;
- HANDLE Handle[thread_num];
- int i = 0;
- While (i < thread_num)
- {
- Handle[i] = (handle) _beginthreadex (NULL, 0, fun, &i, 0, NULL);
- i++; //The main thread may have changed the value of this I when it received the parameter
- }
- //guarantee that the child threads are all running end
- WaitForMultipleObjects (Thread_num, handle, TRUE, INFINITE);
- return 0;
- }
- unsigned int __stdcall fun (void *ppm)
- {
- Because creating a thread is a certain overhead, the new thread is not able to do it the first time.
- int nthreadnum = * (int *) PPM; //Sub-thread get parameters
- Sleep (50); //some work should
- g_nnum++; //Processing global Resources
- Sleep (0); //some work should
- printf ("Thread number%d global resource value is%d\n", Nthreadnum, G_nnum);
- return 0;
- }
The results of the operation can refer to the following illustrations, and it is strongly recommended that you try them yourself.
Figure 1
Figure 2
Figure 3
As you can see, the running results are completely chaotic and unpredictable. This series will use the various tools under the Windows platform, including key segments, events, mutexes, semaphores and so on to solve this problem and make a comprehensive summary, please pay attention.
"Second-kill multithreaded fifth" Classic thread synchronization key section CS has been released, welcome to see.
"Second-kill multithreaded sixth" Classic Thread synchronization events event "has been released, welcome to see.
"Second-kill multithreaded seventh" classic thread synchronization mutex mutex has been released, welcome to see.
"Second-kill multithreaded eighth" classic thread synchronization semaphore semaphore "has been released, welcome to see.
Reprint please indicate source, original address: http://blog.csdn.net/morewindows/article/details/7442333
A classic multi-threaded synchronization problem