[A classic multi-threaded synchronization problem] Summary

For a classic thread synchronization mutex problem, the previous articles proposed four kinds of solutions: Key segment, event, mutex, semaphore.

Here is a summary of these four solutions, combing the knowledge points:

First of all, on the concept of thread synchronization mutual exclusion of knowledge, I believe you through the previous article, has a certain understanding of thread synchronization mutex, can also be vague to say the thread synchronization mutually exclusive knowledge of the various concepts, the following list from the "Computer operating system" in the book selected some of the thread synchronization mutex description. Believe that there is a preliminary and vague impression and then look at the definition of authority, it should be remembered particularly deep.

1. Main tasks for thread (process) synchronization

A: After the introduction of multi-threading, due to the asynchronous execution of the thread, it will cause confusion to the system, especially in emergency critical resources, such as multiple threads emergency the same printer, will make printing results intertwined, difficult to distinguish. When multiple threads share variables, tables, and linked lists in an emergency, it can cause data processing errors, so the main task of thread synchronization is to enable the concurrent execution of the threads to effectively share resources and cooperate with each other, so that the execution result of the program is reproducible.

2. What are the constraints between threads (processes)?

When a thread executes concurrently, the following two constraints exist between use threads due to resource sharing and thread collaboration.

(1) indirect mutual restriction. Multiple threads in a system must share some system resources, such as shared CPUs, shared I/O devices, and so-called indirect mutual constraints originate from this resource sharing, the printer is the best example, and thread a waits for other threads when using the printer.

(2) direct mutual restriction. This restriction is mainly due to the co-operation between threads, such as thread A, which provides the result of the calculation to thread B for further processing, and threads B will be in a blocked state before the data is delivered.

Indirect mutual restriction can be called mutual exclusion, direct mutual restriction can be called synchronization, for mutual exclusion can be understood, and thread A and thread B mutually exclusive access to a resource will be a sequential problem between them-either thread a waits for thread B to finish the operation, or thread B waits for the thread to finish, which is actually the synchronization of the thread. So synchronization includes mutual exclusion, and mutual exclusion is actually a special kind of synchronization.

3. Critical resources and critical areas

A resource that allows only one thread to access for a period of time is called a critical or exclusive resource, and most physical devices in the computer, the shared variable waits in the process are critical resources, and they require mutually exclusive access. The code that accesses the critical resource in each process is called a critical section.

After reading the concept of knowledge, the following table to help you better memory and use of multi-threaded synchronous mutual exclusion of four implementation methods-key segments, events, mutexes, semaphores.

Key segment CS and mutex mutex:

Events Event:

Note that the manual and automatic placement of events should be clearly divided and not confused.

Signal Volume semaphore:

The semaphore indicates a trigger state when the count is greater than 0, the call WaitForSingleObject does not block, equals 0 means the state is not triggered, and the call WaitForSingleObject blocks until another thread increments the count.

Note: mutexes, events, semaphores are kernel objects that can be used across processes (via Openmutex,openevent,opensemaphore).

abandonment issues in thread synchronization

Mutexes are often used for thread mutexes between multiple processes, so it has a more useful feature than critical segments-the handling of " abandonment " situations. For example, if a thread that occupies a mutex terminates unexpectedly before calling ReleaseMutex () to trigger a mutex (equivalent to the mutex being "abandoned"), will all threads waiting for this mutex be caught in an infinite wait process because the mutex cannot be triggered? This is obviously unreasonable. Since the thread that occupies a mutex is terminated, it is sufficient to prove that it is no longer using the resources protected by the mutex, so these resources are fully and should be used by other threads. Therefore, in this " abandonment " case, the system automatically sets the internal thread ID of the mutex to 0, and its recursive counter is reset to 0, indicating that the mutex is triggered. Then the system will "fairly" select a waiting thread to complete the Dispatch (WaitForSingleObject () of the selected thread will return WAIT_ABANDONED_0).

The problem with "abandonment" can be seen--whether the process of owning a resource terminates unexpectedly and the other processes waiting for that resource are aware.

1. The issue of "abandonment" in key sections

[A classic multi-threaded synchronization problem] Summary