Deadlock conditions
From APIDesign
(→Mutual exclusion) |
(→Hold and wait or partial allocation) |
||
| Line 3: | Line 3: | ||
The resources involved must be exclusive. Once a thread gets on hold of a resource, nobody else can use it. Otherwise the concurrent threads would not be prevented from using the resource. | The resources involved must be exclusive. Once a thread gets on hold of a resource, nobody else can use it. Otherwise the concurrent threads would not be prevented from using the resource. | ||
| - | == Hold and wait | + | == Hold and wait == |
| - | + | There must be a way to request another resource while already holding some. If a thread can only request resource(s) while holding none, a deadlock cannot be created. | |
== No pre-emption == | == No pre-emption == | ||
Revision as of 07:47, 19 October 2014
Contents |
Mutual exclusion
The resources involved must be exclusive. Once a thread gets on hold of a resource, nobody else can use it. Otherwise the concurrent threads would not be prevented from using the resource.
Hold and wait
There must be a way to request another resource while already holding some. If a thread can only request resource(s) while holding none, a deadlock cannot be created.
No pre-emption
The processes must not have resources taken away while that resource is being used. Otherwise, deadlock could not occur since the operating system could simply take enough resources from running processes to enable any process to finish.
Resource waiting or circular wait
A circular chain of processes, with each process holding resources which are currently being requested by the next process in the chain, cannot exist. If it does, the cycle theorem (which states that "a cycle in the resource graph is necessary for deadlock to occur") indicated that deadlock could occur.
Follow
