Deadlock conditions
From APIDesign
(→Resource waiting or circular wait) |
|||
| Line 14: | Line 14: | ||
| - | There must be a way to request another resource while already holding some. If a thread can only request resource(s) while holding none (or there is some order of resources and those can be requested only in such order), 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 (or there is some order of resources and those can be requested only in such order), a [[deadlock]] cannot be created. |
Revision as of 08:45, 1 August 2018
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
A thread can hold and wait indefinitely. If it could not, and for example would time out, the deadlock can be resolved by letting the timed out thread to give up and release all resources.
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.
Incremental Requests
There must be a way to request another resource while already holding some. If a thread can only request resource(s) while holding none (or there is some order of resources and those can be requested only in such order), a deadlock cannot be created.
Follow
