Talking about deadlock

1. What is a deadlock

Refers to two or more processes (threads) in the process of execution, because of the contention for resources caused by a mutual waiting phenomenon, if there is no external force, they will not be able to proceed. At this point, the system is in a deadlock state or the system generates a deadlock, and these processes (threads) that are always waiting on each other are called deadlock processes (threads). Because resource consumption is mutually exclusive, when a process requests resources, so that the process (threads) with no external assistance, will never be allocated the necessary resources and can not continue to run, which creates a special phenomenon of deadlock.

First case:

If the same thread calls lock two times, on the second 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, and the thread is suspended without a chance to release the lock, so it is always suspended waiting, which is also called dead Lock (Deadlock).

Second case:

A cross-lock deadlock scenario in which two or more threads in the execution program are permanently blocked (waiting), and each thread waits for resources that are consumed by other threads and blocked. For example, if thread 1 locks record A and waits for record B, and thread 2 locks record B and waits for record A, a deadlock occurs on two threads.

2, the cause of the deadlock

(1) Due to insufficient system resources.
(2) The sequence of progress of the process is not appropriate.
(3) Improper allocation of resources and so on.

If the system has sufficient resources, the resource requests of the process can be met, the likelihood of deadlocks is very low, otherwise it will be locked into a deadlock because of the contention for limited resources. Second, the process is run in a different order and speed, and may also produce a deadlock.

3 . The necessary conditions for the production of deadlocks

(1) Mutex condition: A resource can only be used by one process at a time.
(2) Request and hold condition: When a process is blocked by a request for resources, it remains in place for the resources that have been obtained.
(3) Conditions of deprivation: the resources that the process has acquired cannot be forcibly deprived of until the end of its use.

(4) Cyclic waiting condition: a cyclic waiting resource relationship is formed between several processes.

The above four conditions as long as there is a not satisfied, there will be no deadlock.

4. Deadlock prevention

(1) orderly resource allocation method

This algorithm resource is numbered uniformly on all resources in a certain rule system, and must be in ascending order when applying. The system requires the application process:

1) All resources that it must use and belong to the same category must be completed at one time;

2) in the application of different types of resources, must be in accordance with the number of various types of equipment to apply. For example: Process PA, the order in which resources are used is R1,R2, process PB, the order in which resources are used is R2,R1, and if dynamic allocation is possible to form a loop condition, it can cause deadlock.

Using the ordered resource allocation method: The number of R1 is numbered as 1,R2 2;

PA: The order of application should be: R1,R2

PB: The order of application should be: R1,R2

This destroys the loop condition and avoids the deadlock.

(2) banker algorithm

The most representative algorithm for avoiding deadlock algorithms is the banker algorithm proposed by Dijkstra E.W in 1968:

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.

When studying the resource allocation strategy in the operating system, the limited resources in the system are used by multiple processes, and the resulting resources must be guaranteed to return resources in a limited amount 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 requirement of each process cannot exceed the total amount of resources owned by the system, and the bank algorithm allocates resources to avoid deadlock.

5 . Ways to avoid deadlocks

(1) Lock order

Deadlocks can easily occur when multiple threads require the same locks, but are locked in different order. If you can ensure that all threads are getting locks in the same order, the deadlock does not occur. Sequential lock-In is an effective mechanism for deadlock prevention. However, this approach requires you to know all the locks that may be used in advance, but there are always times when they are unpredictable.

(2) Lock time limit

Another way to avoid deadlocks is to add a timeout when trying to acquire a lock, which means that the thread will discard the lock request if it exceeds the time limit in the attempt to acquire the lock. If a thread does not successfully acquire all the required locks within a given time frame, it will rollback and release all acquired locks, and then wait for a random time to retry. This random wait time gives other threads a chance to try to acquire the same locks, and allows the app to continue running without acquiring a lock (the lock timeout allows you to continue doing something else and then go back and repeat the previously locked logic).

(3) Deadlock detection

Deadlock detection is a better mechanism for deadlock prevention, primarily for scenarios where sequential locking and lock timeouts are not possible.

Whenever a thread obtains a lock, it is written down in the data structure (map, graph, and so on) associated with the lock. In addition, whenever a thread requests a lock, it needs to be recorded in this data structure. When a thread requests a lock failure, the thread can traverse the lock's diagram to see if a deadlock has occurred.

Of course, deadlocks are typically more complex than two threads holding each other's locks. Thread A waits for thread B, thread B waits for thread C, thread C waits for thread d, and thread D waits for thread A. Thread A in order to detect deadlocks, it requires a progressive detection of all locks requested by B. Starting with the lock requested by thread B, thread a found thread C and then found thread D, and found that thread D requested the lock to be held by thread A. This is what it knew happened to be a deadlock.

When a deadlock is detected, it is best to prioritize these threads so that one (or several) threads fall back and the remaining threads continue to hold the locks they need, just as they do not have a deadlock. If the priority given to these threads is fixed, the same batch of threads will always have a higher priority. To avoid this problem, you can set a random priority when a deadlock occurs.

This article is from the "lovemeright" blog, make sure to keep this source http://lovemeright.blog.51cto.com/10808587/1826593

Talking about deadlock