Second kill multithreading fourth article a classic multithreaded synchronization problem

The last "second kill multithreading" the third Atom Operation Interlocked series functions describes the role of atomic operation in multiple processes, now a complex point. This problem involves the synchronization of threads and mutual exclusion, is a very representative of the problem of multithreading synchronization, if you can make it clear, then multithreading synchronization will lay a good foundation.

Program Description:

The main thread starts 10 child threads and passes the variable address representing the subroutine number to the child thread as an argument. The child thread receives parameters-> sleep (0)-> output parameters and global variables,-> global variable + +-> sleep.

Requirements:

1. The line program number for child thread output cannot be duplicated.

2. The output of a global variable must be incremented.

Here's a simple sketch:

Analysis of this problem, the main points of investigation are two:

1. The main thread creates a child thread and passes in a pointer to the variable address as a parameter, because the thread startup takes a certain amount of time, so before the child thread accesses and saves data based on the pointer, the main thread waits for the child thread to save before changing the parameter and starting the next thread. This involves synchronization between the main thread and the child thread .

2. Changes and outputs of global variables that are mutually exclusive between child threads. Requires that the output of global variables be incremented. This involves mutual exclusion between the child threads .

The basic framework of this program is listed below, which can be modified and validated based on this code.

Classic thread sync 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);
		The main thread may change the value of this I when the i++;//and other child threads receive the parameter
	//guarantee that the child thread has all run over
	waitformultipleobjects (Thread_num, handle, TRUE, INFINITE);  
	return 0;
}

unsigned int __stdcall Fun (void *ppm)
{
//due to the overhead of creating a thread, the new thread cannot be executed at the first time
	int nthreadnum = * (int *) PPM ; The child thread gets the parameter sleep
	(m),//some work should to do
	g_nnum++;  Processing global resource Sleep
	(0);//some work should to do
	printf ("Thread number%d  global resource value is%d\n", Nthreadnum, g_nnum);
	return 0;
}

The results of the operation can be referred to the following diagram, strongly recommended to the reader to try.

Figure 1

Figure 2

Figure 3

It can be seen that the results of the operation are completely chaotic and unpredictable. This series will use the Windows platform under various means including key segments, events, mutexes, semaphores and so on to solve this problem and make a comprehensive summary, stay tuned.

"Second kill multithreading fifth Classic thread synchronization key segment CS" has been published, welcome to see.

"Second kill multithreading sixth classic thread synchronization event" has been published, welcome to see.

"Second kill multithreading seventh classic thread synchronization mutex mutexes" has been published, welcome to see.

"Second kill multithreading eighth classic thread sync semaphore semaphore" has been published, welcome to see.

Reprint please indicate the source, the original address: http://blog.csdn.net/morewindows/article/details/7442333