Thread mutex execution-False Lock

Abstract:
In a multi-thread concurrent programming environment, deadlock is a problem we often encounter and often need to solve. Deadlock:Because resource usage is mutually exclusive, when a line (Progress) Requests resources, the relevant process will never be allocated with the assistance of external force and cannot continue to run, this produces a special deadlock.Such:

Thread #1 needs to get lock B after obtaining lock a. At the same time, thread #2 needs to get lock a after lock B. For threads #1 and #2, the deadlock is formed because they cannot obtain the MET conditions and cannot continue execution.
Deadlock is a big problem in multi-thread concurrent programming. We can debug and track it through log trace, multi-thread programming auxiliary tools, IDE debugging environment, and other means. However, another problem that is more difficult to deal with is the "False Lock" (I am calling it a "False Lock" for the time being, but I cannot find any better name ). The so-called false lock is defined as follows:Deadlock within a limited period of time. Unlike deadlocks, the duration of a deadlock is limited. As we all know, the duration of a deadlock is infinite. If a deadlock occurs, the program cannot do anything next. It is precisely because of the relative duration of the false lock that it will bring more trouble to our programmers. As you can imagine, it is very difficult to trace such a specific time period using some tools. In more cases, we need to perform reasonable analysis based on logs, solve the problem. This article will discuss the conditions, environment, and solutions for the occurrence of false locks.
I. Conditions for generating a false lock.

Consider the following example (I just gave a false Code ). Suppose the number of threads in our system is definite and limited. In this example, the total number of threads in the system is 3. For example:

Threads #1, #2, #3 may all be scheduled to enter critical section A. We assume that thread #1 takes 10 seconds to execute critical section A. During these 10 seconds, thread #2 and thread #3 are both in the waiting state. That is to say, during this 10 s, the system cannot respond to any other requests. We call it a 10 s false lock. If the system needs to execute some key requests during this period, these key requests need to be processed in real time. For example, if it is a timer event, the consequences are unimaginable. (Note: we assume that the thread in the system is only #1, #2, #3 ).
Here, we will summarize the conditions for the occurrence of a false lock as follows:
--> --〉 The code in the critical section may be executed by any thread in the system within a concentrated period of time, which is determined by the operating system.
--> --〉 Code in the critical section may be time-consuming in some cases. (For example, the execution time is greater than 100 ms, or even seconds)
2. False lock in proactor (iocp.
In the previous article, I mentioned that on Windows, the proactor design mode is based on iocp. Here, this article will not use too many languages to explain how proactor is designed, focusing on the false lock of proactor and some solutions. In addition, the proactor I mentioned here is equivalent to iocp at the technical level. We can also understand the concept I have explained according to iocp.
We all know that iocp is driven by a worker thread. The worker thread is associated with a completed port object. When I/O requests are shipped to the completed port object, these threads serve the completed port. It should be noted that the number of threads to be created to complete the port service is determined by your application design (it is important to note that: the number of concurrent threads specified when createiocompletionport is called is different from the number of created worker threads. For detailed technical details, see other materials ). But in general, after your system delivers and runs, the number of worker threads is a fixed value. Its structure is roughly as follows:

assume that the worker threads with 4 threads are used to complete port service. They call the getqueuedcompletionstatus method to obtain io-related packages from the completion port, they all call back the code at the business logic layer for relevant business logic processing. Here, we can see that there is a critical mutex in the business logic layer and the worker thread may be scheduled to execute this critical mutex in a specific set period, the conditions for the suspended lock are basically formed. If a thread takes a long time in the region, the suspended lock will occur.
in general, the key to solving such a problem is to break the conditions for the formation of a false lock:
first, in the callback function, minimize the use of locks.
second, reduce the execution time of the critical mutex. Pay special attention to some slow operations. For example, when you access slow Io operations (open files, read/write files, etc.) in the critical mutex, you may need to consider the cache mechanism to replace the slow disk by using memory.
3. Entrust the code of the critical mutex to another independent thread (or thread group) for execution at the cost of increasing the communication between these threads.
fourth, use traffic control and other measures to prevent all threads from accessing the critical mutex during the centralized period.
III. Conclusion:
In fact, once such a problem exists, it is difficult to detect and debug it. However, for multi-threaded programming, we should abide by the following basic principles to maximize the prevention of deadlocks and false locks.

--> Minimize the lock usage frequency and protection scope.
--> When the thread executes code within the protection scope of the mutex lock, it should: minimize access to slow Io devices (such as disk) and avoid obtaining other mutex resources.
--> Correctly use various locks, including atomic operation primitives, read lock, write lock, and recursive lock. These locks play different roles in different scenarios.