First, the synchronization mechanism was introduced to solve three major problems
1 ensure the integrity of shared resources in order to control the synchronization access of shared resources between threads. (for example, if a thread is updating one data and another thread is reading the data, then it is not known whether the data is new or old, in order to avoid this situation)
2 Ensure that the actions between threads are sent in the order in which they are drawn, such as the trigger of a thread, and the result of another thread is required as a condition.
3 in order to control the maximum number of accesses to a shared resource, for example, we can only process requests from 5 customers at the same time, we need to put the queue to wait.
second, the concept of synchronization is to wait
WIN32 provides an API wait function
DWORD WaitForSingleObject (HANDLE hhandle,dword dwmilliseconds);
The parameter 1:hhandle the object handle. You can make a series of objects, such as
Event (events), mutex (mutex), Seamphore (signal) thread (thread), etc.
Parameter 2:dwmilliseconds timing interval unit milliseconds (ms)
1 If you specify a value other than 0, the function waits until the Hhandle tag object is triggered, or the time is up.
2 If the dwmilliseconds is 0, the object is not signaled and the function does not enter a wait state, it returns immediately.
3 If dwmilliseconds is infinite, the object is triggered, the signal is returned, the function returns, and in most cases only the infinite macro is used.
This function is a plug-in function, which means that only this function is completed before it is returned. So he is a synchronous function.
return value:
DWORD DW = WaitForSingleObject (hprocess,5000)
{
Within the specified, the delegate waits for success, triggering the object.
Case WAIT_OBJECT_0:
Appropriate action
Break
The wait time is over, the object is not triggered, no success indicates a timeout
Case Wait_timeout:
Appropriate action
Break
Some errors have occurred, and the thread handle is NULL
Case wait_failed:
//corresponding operation
Break
}
Third, mutex mutex object (synchronization object)
Role:
1 is used to ensure that a thread exclusively accesses a resource
2 contains a usage counter, thread ID, and a recursive count
The ID of the 3 thread is used to identify which thread in the system is currently occupying this mutex
4 The recursive counter indicates the number of times that the thread is consuming this mutex
5 Mutex is one of the most frequently used kernel objects
The main point is that when a shared resource is locked by a thread, other threads cannot access the resource and read and write.
1 Create a Mutex object:
The function of the CreateMutex function is to create a mutex object that returns the object
HANDLE CreateMutex (lpsecurity_attributes lpmutexattributes,//pointers to security properties
BOOL Binitialowner//Initialize mutex object owner
LPCTSTR Lpname//points to the mutex object name
)
Parameter 1 normally uses NULL if we use a cross-access error.
Parameter 2 is usually false, so the thread ID and the recursive counter are set to 0.
Parameter 3 Specifies the mutex object name, if and if there is an event that owns this, name, then open an existing named mutex, the name may not be the existing event, the signal machine can wait for the timer or file mapping to match.
General usage: HANDLE Mutex = CreateMutex (NULL,FALSE,NUKL);
2 Releasing the Mutex object:
ReleaseMutex function
BOOL WINAPI ReleaseMutex (
HANDLE Hmutex);
Hmutex: A handle to a mutex object
Role: This function will reduce the object's recursive counter by 1, and if the thread has successfully waited for the mutex object more than once, then the thread must call release the same number of times
To make the object's recursive counter change to 0. When the recursive counter is 0 o'clock, the function also sets the thread ID to 0 so that the mutex is in the triggered state.
We found that the recursive counter and ID of the mutex object was created at 0 (that is, in the trigger state), and when it would increase the non-triggering state.
3 operation flow of the entire mutex: (lock and unlock process)
Suppose: There is a global file pointer, and there are multiple threads that need to read and write the file pointer, but, in order to ensure the integrity of the resources, we at the same moment,
Only one thread is allowed to read and write operations.
Locking
in order to gain access to the protected resources, Threads to invoke a wait function and transfer to the mutex created earlier Handle , in the interior, The wait function checks if the thread ID is 0 ( if 0 is the trigger state ) If it is 0, then function will set the thread ID in the mutex handle to the ID of the current calling thread , (only this locked thread is
allows read and write access to a resource. ) and set the recursive counter to 1, at which point
The mutex is in a non-triggering state , the thread ID assignment to the mutex and the recursive counter increase are atomic operations, so-called Atomic operation, is that means the operating system guarantees that the atomic operation is not performed before the The switch of the thread, The current thread then continues to run.
Unlock:
Assuming that a thread succeeds in obtaining a mutex, the thread knows that it has exclusive access to the protected resource, and any view that waits for the mutex to get
The thread that accesses the resource will enter the wait state, and it is important to: when a thread enters a wait state, it does not consume the CPU clock frequency . When an exclusive thread is on a resource
When you are done, you must call the ReleaseMutex function (free) to subtract the recursive counter of the mutex by 1, and if the value of the recursive counter is 0 , the thread ID
set to 0 , so that the mutex is in the trigger state again.
The point of attention of the mutex:
1 thread ID and recursive counter increments can only be performed in the wait (wait) function.
2 You must call the release function, or it will always increment to cause a deadlock .
This article is from the "12148490" blog, please be sure to keep this source http://12158490.blog.51cto.com/12148490/1950808
VC + + Multithreading synchronization (a) Mutex mutex