Windows core programming-mutexes)

Thread Synchronization Methods include critical section, mutex, event, and semaphore.
The front side talked about thread synchronization in the critical section ----- windows core programming-key section (critical section) thread synchronization. In this chapter, I will introduce the use of mutexes in thread synchronization.
Mutexes is similar to the critical section. For example, only one thread can own mutex within a time period, it is as if only one thread can enter the same critical section at a time. However, mutex improves flexibility and becomes more powerful by sacrificing the speed.

Although mutex and critical sections do the same thing, their operations are still different:
1. Locking an unowned mutex takes almost 100 times more time than locking an unowned critical section.
2. mutex can be used across processes. The critical section can only be used in the same process.

3. When waiting for a mutex, you can specify the length of the world of "end wait", but not for the critical section.

The main cause of the above difference is that mutex is the kernel object and the critical section is not the kernel object.

Comparison of mutex and critical section functions is as follows:

Critical Section	Mutex
Critical_section Initializecriticalsection ()	Createmutex () Openmutex ()
Entercriticalsection ()	Waitforsingleobject () Waitformultipleobjects () Msgwaitformultipleobjects ()
Leavecriticalsection ()	Releasemutex ()
Deletecriticalsection ()	Closehandle ()

Note the following when using mutex:

In an appropriate program, a thread should never have a mutex before it is about to end, because this means that the thread cannot properly clear its resources. Unfortunately, we are not in a perfect world. Sometimes, for some reason, the thread may not call releasemutex () before the end (). To solve this problem, mutex has a very important feature. This property is unique among various synchronization mechanisms. If a thread has a mutex and does not call releasemutex () before the end, mutex will not be destroyed. Instead, the mutex is regarded as "not owned" and "not stimulated", and the thread in the next wait will be notified with wait_abandoned_0. This situation exists whether the thread ends because of exitthread () or when it ends.

Any time you want to lock more than one synchronization object, you have a potential cause of deadlock.
If you always lock all objects at the same time, the problem can be solved.
The following is an example of a potential deadlock:

Void swaplists (list * list1, list * list2) {entercriticalsection (list1-> critical_sec); entercriticalsection (list2-> critical_sec); // list1, list2 leavecriticalsection (list1-> critical_sec); leavecriticalsection (list2-> critical_sec );}

Correct practice:

Void swaplists (list * list1, list * list2) {handle arrhandles [2]; arrhandles [0] = list1-> hmutex; arrhandles [1] = list2-> hmutex; waitformultipleobjects (2, arrhandles, true, infinite); // list1, list2 data exchange releasemutex (arrhandles [0]); releasemutex (arrhandles [1]);}

Introduction to semaphores ----- windows core programming-semaphores (semaphore)