multithreading deadlock generation and how to avoid deadlocksOriginal July 13, 2016 11:07:45 Tags: multithreading/deadlock 34604
definition of a deadlockMultithreading and multiple processes improve the utilization of system resources and improve the processing capacity of the system. However, concurrent execution also poses a new problem-deadlock. A deadlock is a deadlock in which multiple threads are competing for resources (waiting for each other), and without external forces, these processes cannot be pushed forward.
Here are some examples to illustrate the deadlock phenomenon.
First look at an example of life, 2 people eat together but only a pair of chopsticks, 2 people take turns to eat (also have 2 chopsticks to eat). At one time, one took the left chopsticks, one took the right chopsticks, 2 people both occupy a resource, waiting for another resource, this time a while waiting for the second to eat and release the chopsticks it occupies, the same, B is also waiting for a eat and release its possession of chopsticks, so caught in a dead cycle, who can not continue to eat ...
Similar situations exist in computer systems. For example, there is only one printer and one input device in a computer system, the process P1 is consuming an input device while making a request to use a printer, but at this point the printer is being occupied by the process P2, and P2 is requesting to use the input device being P1 before releasing the printer. Such two processes are endlessly waiting for each other to continue execution, at which point two processes fall into deadlock state.
second, the cause of the deadlock
1 Competition of system resourcesOften the system has the inalienable resources, the number of which is not enough to meet the needs of multiple processes, so that the process in the course of running, because of contention for resources and deadlock, such as tape drives, printers and so on. Only the competition for the inalienable resources could lead to deadlock, and the competition for the disenfranchised resources would not cause deadlock.
2 process Advance order illegalWhen a process is running, the request and release of resources are not in the wrong order and can also cause deadlocks. For example, concurrent processes P1, P2 maintain resource R1, R2, and Process P1 request resource R2, when the process P2 request Resource R1, both are blocked because the required resources are occupied.
Improper use of the semaphore can also cause deadlock. The process of waiting for messages from one another to each other can make it impossible for these processes to move forward. For example, process a waits for a message from process B, and process B waits for a message from process A to see that processes A and B are not competing for the same resource, but are waiting for the other's resources to cause a deadlock.
3) The necessary conditions for deadlock productionA deadlock must meet the following four conditions, and the deadlock will not occur if either of these conditions is not true. Mutex: The process requires exclusive control over the allocated resources (such as printers), i.e. a resource is occupied by only one process over a period of time. At this point, if there are other processes requesting the resource, the request process can only wait. Non-deprivation of condition: the resource acquired by a process cannot be forcibly taken away by another process until it has been used, that is, it can only be freed by the process that acquired the resource (only active release). Request and retention conditions: The process has maintained at least one resource, but a new resource request has been made, and the resource is already occupied by another process, at which point the request process is blocked, but the resources that it has obtained remain in place. Loop wait Condition: There is a cyclic wait chain for process resources, and each process in the chain is requested by the next process in the chain. That is, there is a process set in the waiting state {Pl, P2, ..., PN}, where the resources for pi waiting are occupied by P (i+1) (i=0, 1, ..., n-1), and the resources for the PN wait are P0 occupied, as shown in Figure 2-15.
Intuitively, the loop wait condition seems to be the same as the deadlock definition. The requirement for a deadlock definition to constitute a wait ring is stricter, and it requires that the resource that pi waits for must be satisfied by P (i+1), while the cyclic wait condition has no such limit. For example, the system has two output devices, P0 occupies one, PK occupies another, and K does not belong to the set {0, 1, ..., n}.
PN waits for an output device that can be obtained from the P0, or possibly from PK. Therefore, although the PN, P0 and some other processes formed a circular waiting loop, but PK is not in the circle, if PK released the output device, you can break the cycle waiting, as shown in Figure 2-16. Therefore, cyclic waiting is only a necessary condition for deadlocks.
Resource allocation diagram contains a circle and the system does not necessarily have a deadlock because the number of similar resources is greater than 1. However, if each kind of resource in the system has only one resource, the resource allocation graph containing the circle becomes the sufficient and necessary condition for the system to appear deadlock.
An example of a deadlock
[Java] View Plain copy/** * A simple deadlock class * when the Deadlock class object Flag==1 (TD1), first lock O1, Sleep 500 ms * while TD1 in sleep another Flag==0 object (TD2) thread starts, Locks O2 first, sleeps 500 milliseconds * TD1 after the end of the sleep need to lock O2 to continue execution, and at this time O2 has been td2 locked; * TD2 After the end of sleep need to lock O1 to continue execution, and at this time O1 has been td1 locked; * TD1, TD2 wait for each other, all need to get the other locked resources to continue execution, thereby deadlock. */ public class deadlock implements runnable { public int flag = 1; //static objects are shared by all objects of the class private Static object o1 = new object (), o2 = new object (); @Override public void run () { system.out.println ("flag=" + flag); if ( flag == 1) { synchronized (O1) { try { Thread.Sleep ( ); } catch (exception e) { E.printstacktrace (); } synchronized (O2) { system.out.println (" 1 "); } } } if (flag == 0) { synchronized (O2) { try { thread.sleep ( ); } catch (exception e) { e.printstacktrace (); } synchronized (O1) { system.out.println (
