Deadlock conditions
From APIDesign
(→Hold and wait or partial allocation) |
(→No pre-emption) |
||
| Line 7: | Line 7: | ||
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. | 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. | ||
| - | == | + | == Cannot Take Away a Resource == |
| - | + | Nobody can take away a resource from a thread. If there was a supervisor, that could take the resource away, it could effectively solve all deadlocks by detecting them (which is easy) and then choosing a thread to loose its resource while letting others proceed. | |
== Resource waiting or circular wait == | == Resource waiting or circular wait == | ||
Revision as of 07:49, 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.
Cannot Take Away a Resource
Nobody can take away a resource from a thread. If there was a supervisor, that could take the resource away, it could effectively solve all deadlocks by detecting them (which is easy) and then choosing a thread to loose its resource while letting others proceed.
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
