Deadlock conditions

From APIDesign

Revision as of 07:45, 19 October 2014 (edit) JaroslavTulach (Talk | contribs) (New page: == Mutual exclusion == The resources involved must be unshareable; otherwise, the processes would not be prevented from using the resource when necessary. == Hold and wait or partial al...) ← Previous diff		Current revision (05:33, 10 October 2023) (edit) (undo) JaroslavTulach (Talk | contribs)
(7 intermediate revisions not shown.)
Line 1:		Line 1:
-	== Mutual exclusion ==	+	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.
-	The resources involved must be unshareable; otherwise, the processes would not be prevented from using the resource when necessary.	+	== 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 or partial allocation ==	+	== Hold and wait ==
-	The processes must hold the resources they have already been allocated while waiting for other (requested) resources. If the process had to release its resources when a new resource or resources were requested, deadlock could not occur because the process would not prevent others from using resources that it controlled.	+	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.
-	== No pre-emption ==	+	== Cannot Take Away a Resource ==
-	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.	+	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 ==	+	== Incremental Requests ==
-	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.
-	[http://www.google.com/search?q=four+necessary+condition+for+a+deadlock+to+appear&start=0&start=0&ie=utf-8&oe=utf-8 four necessary and also sufficient conditions]	+	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 1 Mutual exclusion 2 Hold and wait 3 Cannot Take Away a Resource 4 Incremental Requests

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.