Four conditions for deadlock on Linux thread

I. Causes and conditions of deadlock

1. The concept of deadlock

in general, if the same thread calls lock two times, at the first call, because the lock is already occupied, the thread suspends waiting for the other thread to release the lock, but the lock is occupied by itself, the thread is suspended, there is no chance to release the lock, and therefore, it is always suspended waiting, which is called a deadlock ( Deadlock). Another typical deadlock scenario is this: thread a obtains lock 1, thread B obtains lock 2, and thread A calls lock to attempt to acquire lock 2, and the result is that the thread B is required to suspend waiting for thread B to release the lock 2, and at this point, a call to lock is attempted to obtain lock 1, the result is a pending thread a release lock 1 So threads A and B are always in a suspended state.

The so-called deadlock, refers to the multiple threads in the process of contention for resources caused by a deadlock (deadlyembreace) is the phenomenon of waiting for each other, when the thread is in this stalemate, if there is no external force, they will not be able to push forward.

2. Causes of deadlocks

(1). Competitive resources. When the number of resources, such as printers, public queues, etc., which are shared by multiple threads in the system, is insufficient to meet the needs of the threads, it causes the threads to compete against the resources and generate deadlocks.

(2). The order of advance between threads is illegal. In the process of running a thread, the order of requests and releases of resources is incorrect, which can also lead to thread deadlock.

Here's a detailed analysis of the cause of the deadlock:

(1) Competition resources cause deadlock

1) Deprivation and non-deprivation of resources

The resources of the system can be divided into two categories, one of which is a kind of deprivation resource, which means that a thread can be stripped of other threads or systems after acquiring such resources. High-priority threads can deprive resources of low-priority threads. and the switch between threads. The other is the non-deprivation of resources, when the system to allocate such resources to a thread, can not be forcibly withdrawn, only after its use of self-release, such as tape drives, printers and so on.

2). Competition for non-deprivation of resources

The non-deprivation resources configured in the system, because their number can not meet the needs of the threads, will make the thread in the process of contention for these resources deadlock.

3). Competition for temporary resources

Printer resources are sequential, reusable resources called permanent resources. A temporary resource is a resource that is useless after being used by a thread for a short period of time, so it is also called a expendable resource, and it can also cause a deadlock.

(2). Thread push sequence improperly causes deadlock

as mentioned at the beginning Thread A gets lock 1, thread B gets lock 2, and thread A calls lock to try to get lock 2, and the result is that it needs to suspend waiting for thread B to release lock 2, and thread B also calls lock to try to get lock 1, and the result is to suspend waiting for thread A to release lock 1. So both threads A and B will always be in a suspended state.

3. The necessary conditions for generating a deadlock

Although a thread may deadlock while it is running, it must also have a certain condition for the deadlock to occur. In summary it is not difficult to see that the occurrence of deadlocks must have the following four necessary conditions.

(1) . Mutex conditions : A thread uses the allocated resources for exclusive use, that is, a resource is occupied by only one thread for a period of time. If there are other threads requesting the resource at this point, the requestor can wait until the thread that owns the resource is freed.

(2) . Request and hold condition : The thread has kept at least one resource, but a new resource request has been made, and the resource has been taken possession of by another thread, or has already owned the resource but has requested again, at this time the request thread is blocked, But keep the resources you've got.

(3) No deprivation condition: refers to the thread in the resources that have been obtained, before the end of use, can not be deprived, can only be released by themselves when the use is complete.

(4) . loop wait Condition : When a deadlock occurs, there must be a thread-the circular chain of the resource, the thread collection {P0,P1,P2,P3,... The P0 in PN} is waiting for P1 to occupy the resources, P1 is waiting for the resources that the P2 occupies, ..., and PN is waiting for resources that have been consumed by the P0.

4. Basic methods for handling deadlocks

In order to ensure the normal operation of the threads in the system, the necessary measures should be taken beforehand to prevent the deadlock. After a deadlock has occurred in the system, the thought should be detected in time, and appropriate measures should be taken to relieve the deadlock. Currently, the method of handling deadlocks can be attributed to the following four types:

(1). Prevent deadlocks . This is a simpler and more intuitive approach. The method is to prevent deadlocks by setting certain constraints to destroy one or more of the four necessary conditions that produce deadlocks. However, due to the restrictive conditions imposed, the system resource utilization and system throughput is low.

(2). Avoid deadlocks . This method is also a pre-prevention strategy, but it does not have to take a variety of restrictive measures to destroy the four necessary conditions to generate deadlocks, but in the dynamic allocation process of resources, in a way to prevent the system into unsafe state, so as to avoid the deadlock. This method can obtain higher resource utilization and system throughput by applying the weaker constraints beforehand, but it has some difficulty in fact. This method is commonly used in more sophisticated systems to avoid deadlocks.

(3). Deadlock Detection . This method does not need to take any restrictive measures beforehand, and does not have to check if the system has entered the unsafe zone, but rather allows the system to deadlock during operation. However, the detection mechanism set up by the system can detect the occurrence of the deadlock in time, and determine the thread and resources related to the deadlock, and then take appropriate measures to remove the deadlock from the system.

(4). Unlocking the deadlock . This is a measure to match the detection of deadlocks. When a deadlock has been detected in the system, the thread must be freed from the deadlock state. A common practice is to undo or suspend some threads in order to reclaim some resources, and then assign those resources to a thread that is already in a blocked state, so that it is ready to continue running. Deadlock detection and cancellation measures may make the system obtain better resource utilization and throughput, but the implementation of the most difficult.

Ii. methods of preventing deadlocks

(a) The method of preventing deadlocks is to prevent deadlocks by making one of the 2nd, 3, and 4 conditions of the four prerequisites not tenable. As for the necessary conditions 1, because it is determined by the inherent characteristics of the equipment, not only cannot change, but also should be guaranteed.

1. Rejection of "request and hold conditions"

When this approach is used, the system requires all threads to request all the resources they need for the entire operation before they start running.

Advantages: Simple, easy to implement and safe

Cons: Resource is severely wasted, thread run is delayed

2. Abandoning the "no deprivation" condition

In adopting this method, the system specifies that the thread is asking for resources on a per-request basis. When a thread that has already maintained some resources is not immediately satisfied by making a new request for the resource, it must release all resources it has maintained and reapply again later if needed.

This approach is more complex and costly to implement. And it is possible to delay the execution of the process indefinitely, and also increase the system overhead and reduce the system throughput.

3. Discard the "loop wait" condition

This method specifies that all resources are queued linearly by type and given different serial numbers.

Advantages: Significant improvements in resource utilization and system throughput

Cons: (1) The number of resources must be relatively stable, limiting the increase of new types of equipment

(2). Restrict user's simple and autonomous programming.

(3). Waste of resources

(ii) System security status

1. Security Status

In the method of avoiding deadlocks, threads are allowed to request resources dynamically, but the security of this allocation should be calculated before the system allocates resources. If this allocation does not cause the system to enter an unsafe state, the resource is assigned to the thread, otherwise it waits.

The so-called security state, refers to the system can be a certain line of program column, to allocate resources for each thread, until each thread to meet the maximum resource requirements, so that each thread can be completed smoothly. If the system cannot find such a security sequence, the system is in an unsafe state.

While not all unsafe states are bound to become deadlocked, the system may enter a deadlock state after entering an unsafe state, but the system can avoid entering a deadlock state as long as the system is in a safe state.

Banker Algorithm

The most representative algorithm in the avoidance deadlock algorithm is Dijkstra E.W in 1968. Banker Algorithm :

The banker algorithm is an important way to avoid deadlocks, and the mechanism of preventing deadlocks can only ensure that one of the four conditions above does not occur, and the system will not deadlock. Through this algorithm can be used to solve real life problems, such as bank loans.

Program implementation ideas The banker algorithm is derived from the bank's borrowing business, a certain amount of principal should be a number of clients of the loan turnover, in order to prevent the banker's capital can not be closed, for each loan, must examine whether it is able to return the time limit. There are similar problems when studying the resource allocation strategy in the operating system, and the limited resources in the system can be used by multiple processes, and the process of the resources must be guaranteed to return resources for a limited period of time for other processes to use resources. If the resource allocation is not available, a process cycle waits for the resource, and the process cannot continue the deadlock phenomenon.

Record a process need and occupied resources in process control, assuming that the process Control block PCB where "state" has ready state, waiting state and completion state. When the process is in a waiting state, the system cannot satisfy the current resource request for the process. Total resource requirements represents the total amount of resources that the process will request during the entire execution process. Obviously, the total resource requirements of each process cannot exceed the total number of resources owned by the system, and the banker algorithm allocates resources to avoid deadlocks.

This is a phenomenon that tells the deadlock in the process, which is also true in the thread.

Third, the detection of the deadlock is lifted

1. Deadlock Detection

(1). The system must save request and assignment information about the resource

(2). The system must provide an algorithm to use this information to detect if the system has entered a deadlock state.

2. Release of the deadlock

(1). Deprivation of resources

(2). Undo Thread

This article is from the "fringe" blog, so be sure to keep this source http://ab6107.blog.51cto.com/10538332/1765422

Four conditions for deadlock on Linux thread