Deadlock conditions
From APIDesign
| (One intermediate revision 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 == | ||
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
