The four synchronization mechanisms of threads are as follows:
1. Event uses events (event) to synchronize the thread is the most flexible. An event has two states: excitation state and unstimed state. Also known as the signal state and no signal state. Event is divided into two types: manual reset events and automatic reset events. The manual reset event is set to an excitation state, and all waiting threads are awakened, and it is maintained in an excitation state until the program is resented to an unstimed state. After the automatic reset event is set to the excitation state, the "one" waits will be awakened, and then automatically recover to unstimed state. So use the automatic reset event to synchronize the two threads. The corresponding class in the MFC is CEVENT.. The CEVENT constructor creates an automatic reset event by default and is inactive. There are three functions to change the status of the event: setEvent, resetEvent, and PulseEvent. Synchronizing threads with events is a relatively ideal approach, but in the actual use process, it is important to call STEVENT and PULSEEVENT for automatic reset events. It must be careful.
2, Critical Section uses the first advice of critical regions to lock a resource for a long time. The long time here is relative, depending on the different procedures. For some control software, it may be a few milliseconds, but for another program, it can be as long as several minutes. However, after entering the critical region, you must leave as soon as possible and release resources. What will happen if you don't release it? What is the answer? If it is the main thread (GUI thread) to enter a critical area without being released, huh, the program will hang! A disadvantage in the critical region is that critical section is not a core object, which cannot be learned to enter the critical area is dead. If the thread entering the critical area is hung, there is no release of critical resources, the system is unable to know, and there is no way to release the critical Resource. This disadvantage has been compensated in the mutex (MUTEX). The corresponding implementation class of Critical Section in the MFC is CcriticalSection. CcriticalSECTION :: Lock () Enter the critical area, ccriticalsection :: unlock () leaves the critical area.
3, the functionality and critical region of the MUTEX mutester is very similar. The difference is: Mutex spends more than Critical Section, but Mutex is a core object (Event, Semaphore is also), can be used across processes, and waiting for a locked MUTEX to set Timeout, not like critical section That is unable to know the situation of the critical region, and always die. The corresponding class in the MFC is CMutex. The Win32 function is: Create mutual CreateMutex (), open the mutector OpenMutex (), release the mutesememutex (). Mutex's ownership is not that the thread that produces it, but the last thread that waits for this Mutex (WaitforsingleObject, etc.) and has not yet performed the ReleaseMutex () operation. The thread has Mutex as if it enters Critical Section, only one thread can have the MUTEX at a time. If a thread with MUTEX is not called ReleaseMutex () before returning, then this MUTEX is abandoned, but when other threads are waiting (WaitForsingleObject, etc.), still returns, and get a WAIT_ABANDONED_0 return value. It is possible to know that a MUTEX is abandoned is Mutex unique.
