Deadlock conditions
From APIDesign
(→Hold and wait) |
|||
| (3 intermediate revisions not shown.) | |||
| Line 1: | Line 1: | ||
| + | Fighting problems with [[ImpossibleThreading|threading may seem impossible]], but there is an easy way avoid [[deadlock]]s. Just make sure '''one''' (enough if only one) of following conditions isn't true. Then a [[deadlock]] cannot occur. | ||
| + | |||
== Mutual exclusion == | == Mutual exclusion == | ||
| Line 11: | Line 13: | ||
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. | 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. | |
Current revision
Fighting problems with threading may seem impossible, but there is an easy way avoid deadlocks. Just make sure one (enough if only one) of following conditions isn't true. Then a deadlock cannot occur.
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
