Thread synchronization----critical area and mutex quantity

The coordination of processes and threads in Win32 is done by the synchronization mechanism, which is equivalent to a traffic light between threads.

I. Synchronous and asynchronous

As an example:

PostMessage (), is to put the message in each other's message queue, and then regardless of 3,721, go back to the original call point to continue execution, which is asynchronous.

SendMessage (), just like calling a generic function until the call function ends, will return to the origin, which is the synchronization behavior.

Two. Critical Sections

If a thread has entered a critical section, the other thread must never be able to enter the same critical section.

Initializes a critical zone
VOID initializecriticalsection (
  lpcritical_section lpcriticalsection  //critical section
);

Eliminates a critical region
VOID deletecriticalsection (
  lpcritical_section lpcriticalsection   //critical section
);

Enter the critical zone
VOID entercriticalsection (
  lpcritical_section lpcriticalsection  //critical section
);

Leave the Critical zone
VOID leavecriticalsection (
  lpcritical_section lpcriticalsection   //critical section
);

For example:
critical_section gcriticalsection;

void Function ()
{
    initializecriticalsection (&gcriticalsection);

    EnterCriticalSection (&gcriticalsection);

    Do something here

    leavecriticalsection (&gcriticalsection);

    DeleteCriticalSection (&gcriticalsection);

Once a thread enters a critical section, it can repeatedly enter the critical section, and of course each entry operation must correspond to a departure operation.

That is, EnterCriticalSection (), which can be nested.

But never call sleep () in the critical section, or any wait. () function.

The disadvantage of the critical area is that there is no way to know if the thread entering the critical section is alive or dead. If the thread is dropped after entering the critical section and does not exit, then the system has no way to eliminate the critical section.

Three. mutexes

The mutexes use is very similar to the Critical section, where a thread has a mutex just as a thread enters the Critical section, but it sacrifices speed to increase elasticity.

Once no thread has the mutex, the mutex is in an excited state

The difference between it and the critical section is:

1. mutexes operations are much more time-consuming than Critical.

2. Mutexes can be used across processes, Critical section can only be used in the same process.

3. When waiting for a Mutex, you can specify the length of "End Wait", while Critical section is not.

HANDLE CreateMutex (
  lpsecurity_attributes lpmutexattributes,  //security properties, default to null
  BOOL Binitialowner,                       / /initial owner
  LPCTSTR lpname                            //Mutex name, is a string
);
Return value: Returns NULL

handle OpenMutex (
  DWORD dwdesiredaccess,  //Access
  BOOL If handle is successfully returned) bInheritHandle,    //inheritance option
  LPCTSTR lpname          //object name
);
Opens an existing mutex

BOOL ReleaseMutex (
  HANDLE hmutex   //HANDLE to Mutex
);

The call process is as follows: CreateMutex ();//create waitforxxxobject ();//
wait for

ReleaseMutex ();//release of
CloseHandle ();// Shut down

Description

1. Ownership of a Mutex:

The ownership of a mutex does not belong to the thread that generated it, but to the thread that finally waitxxx () the mutex and has not releasemutex () operations.

2. mutexes are discarded:

If the thread does not call ReleaseMutex () before the end, for example, the thread invokes ExitThread () or ends when it is dropped. Instead of being destroyed, the mutex is considered "not owned" and "not fired", and the next waitxxx () thread is notified by WAIT_ABANDONED_0 (Wait_abandoned_0_n + 1).

3. Originally owned by:

CreateMutex (), the second parameter Binitialowner, allows you to specify whether the existing thread immediately has the resulting mutex.

If you do not specify an immediate possession:

HANDLE Hmutex = CreateMutex (NULL, FALSE, "Sample Name");

int result = WaitForSingleObject (Hmutex, INFINITE);

It can happen that, after the CreateMutex is complete, the context switch occurs and the execution power switches to another thread, and it is possible for other processes to lock the mutex object before the creator of the mutex invokes WaitForSingleObject ().