Editing Deadlock (computer science)

{{short description|State in which members are blocking each other}}
{{Use dmy dates|date=April 2021}}

[[File:Process deadlock.svg|thumb|right|Both processes need resources to continue execution. ''P1'' requires additional resource ''R1'' and is in possession of resource ''R2'', ''P2'' requires additional resource ''R2'' and is in possession of ''R1''; neither process can continue.]]
[[File:Deadlock at a four-way-stop.gif|thumbnail|right|Four processes (blue lines) compete for one resource (grey circle), following a right-before-left policy. A deadlock occurs when all processes lock the resource simultaneously (black lines). The deadlock can be resolved by breaking the symmetry.]]

In [[concurrent computing]], '''deadlock''' is any situation in which no member of some group of entities can proceed because each waits for another member, including itself, to take action, such as sending a message or, more commonly, releasing a [[Lock (computer science)|lock]].<ref name=coulouris>{{cite book|last=Coulouris|first=George|publisher=Pearson|year=2012|title=Distributed Systems Concepts and Design|page=716|isbn=978-0-273-76059-7}}</ref> Deadlocks are a common problem in [[multiprocessing]] systems, [[parallel computing]], and [[Distributed computing|distributed systems]], because in these contexts systems often use software or hardware locks to arbitrate shared resources and implement [[Synchronization (computer science)|process synchronization]].<ref name=para_enclo>{{cite book |last=Padua |first=David |url=https://books.google.com/books?id=Hm6LaufVKFEC&q=deadlock&pg=PA524 |publisher=Springer |year=2011 |title=Encyclopedia of Parallel Computing |page=524 |isbn=9780387097657 |access-date=16 October 2020 |archive-date=18 April 2021 |archive-url=https://web.archive.org/web/20210418033928/https://books.google.com/books?id=Hm6LaufVKFEC&q=deadlock&pg=PA524 |url-status=live }}</ref>

In an [[operating system]], a deadlock occurs when a [[process (computing)|process]] or [[thread (computing)|thread]] enters a waiting [[Process state|state]] because a requested [[system resource]] is held by another waiting process, which in turn is waiting for another resource held by another waiting process.<ref name="Falsafi Midkiff Dennis Dennis 2011 pp. 524–527">{{cite book | last1=Falsafi | first1=Babak | last2=Midkiff | first2=Samuel | last3=Dennis | first3=JackB | last4=Dennis | first4=JackB | last5=Ghoting | first5=Amol | last6=Campbell | first6=Roy H | last7=Klausecker | first7=Christof | last8=Kranzlmüller | first8=Dieter | last9=Emer | first9=Joel | last10=Fossum | first10=Tryggve | last11=Smith | first11=Burton | last12=Philippe | first12=Bernard | last13=Sameh | first13=Ahmed | last14=Irigoin | first14=François | last15=Feautrier | first15=Paul | last16=Praun | first16=Christoph von | last17=Bocchino | first17=Robert L. | last18=Snir | first18=Marc | last19=George | first19=Thomas | last20=Sarin | first20=Vivek | last21=Jann | first21=Joefon | title=Encyclopedia of Parallel Computing | chapter=Deadlocks | publisher=Springer US | publication-place=Boston, MA | year=2011 | doi=10.1007/978-0-387-09766-4_282 | pages=524–527 | isbn=978-0-387-09765-7 | s2cid=241456017 | quote=A deadlock is a condition that may happen in a system composed of multiple processes that can access shared resources. A deadlock is said to occur when two or more processes are waiting for each other to release a resource. None of the processes can make any progress.}}</ref> If a process remains indefinitely unable to change its state because resources requested by it are being used by another process that itself is waiting, then the system is said to be in a deadlock.<ref name="os_galvin">{{cite book|last=Silberschatz|first=Abraham|url=https://books.google.com/books?id=WjvX0HmVTlMC&q=deadlock+operating+systems|publisher=Wiley-India|year=2006|title=Operating System Principles|edition=7th|page=237|isbn=9788126509621|access-date=16 October 2020|archive-date=25 January 2022|archive-url=https://web.archive.org/web/20220125085137/https://books.google.com/books?id=WjvX0HmVTlMC&q=deadlock+operating+systems|url-status=live}}</ref>

In a [[communications system]], deadlocks occur mainly due to loss or corruption of signals rather than contention for resources.<ref name=invi_comp>{{cite book |last=Schneider |first=G. Michael |url=https://books.google.com/books?id=gQK0pJONyhgC&q=deadlock+signal+lost&pg=PA271 |publisher=Cengage Learning |year=2009 |title=Invitation to Computer Science |page=271 |isbn=978-0324788594 |access-date=16 October 2020 |archive-date=18 April 2021 |archive-url=https://web.archive.org/web/20210418025125/https://books.google.com/books?id=gQK0pJONyhgC&q=deadlock+signal+lost&pg=PA271 |url-status=live }}</ref>

[[File:Two processes, two resources.gif|thumbnail|Two processes competing for two resources in opposite order.{{ordered list|style=margin-top:0.5em|list_style_type=upper-alpha
| A single process goes through.
| The later process has to wait.
| A deadlock occurs when the first process locks the first resource at the same time as the second process locks the second resource.
| The deadlock can be resolved by cancelling and restarting the first process.}}]]

==Individually necessary and jointly sufficient conditions for deadlock==
A deadlock situation on a resource can arise only if all of the following conditions occur simultaneously in a system:<ref>{{cite book|last=Silberschatz|first=Abraham|url=https://books.google.com/books?id=WjvX0HmVTlMC&q=deadlock+operating+systems|publisher=Wiley-India|year=2006|title=Operating System Principles|edition=7|page=239|isbn=9788126509621|access-date=16 October 2020|archive-date=18 April 2021|archive-url=https://web.archive.org/web/20210418013932/https://books.google.com/books?id=WjvX0HmVTlMC&q=deadlock+operating+systems|url-status=live}}</ref>
# ''[[Mutual exclusion]]:'' multiple resources are not shareable; only one process at a time may use each resource.<ref>{{Cite book|title=Operating System Concepts|publisher=Wiley|year=2012|isbn=978-1-118-06333-0|pages=319}}</ref><ref>{{cite web|url=http://nob.cs.ucdavis.edu/classes/ecs150-1999-02/dl-cond.html|title=ECS 150 Spring 1999: Four Necessary and Sufficient Conditions for Deadlock|website=nob.cs.ucdavis.edu|access-date=29 April 2018|url-status=live|archive-url=https://web.archive.org/web/20180429180831/http://nob.cs.ucdavis.edu/classes/ecs150-1999-02/dl-cond.html|archive-date=29 April 2018}}</ref>
# ''Hold and wait'' or ''resource holding:'' a process is currently holding at least one resource and requesting additional resources which are being held by other processes.
# ''No [[Preemption (computing)|preemption]]:'' a resource can be released only voluntarily by the process holding it. 
# ''Circular wait:'' each process must be waiting for a resource which is being held by another process, which in turn is waiting for the first process to release the resource. In general, there is a [[set (mathematics)|set]] of waiting processes, ''P'' = {''P''<sub>1</sub>, ''P''<sub>2</sub>, ..., ''P''<sub>''N''</sub>}, such that ''P''<sub>1</sub> is waiting for a resource held by ''P''<sub>2</sub>, ''P''<sub>2</sub> is waiting for a resource held by ''P''<sub>3</sub> and so on until ''P''<sub>''N''</sub> is waiting for a resource held by ''P''<sub>1</sub>.<ref name="os_galvin"/><ref name=embb>{{cite book |last=Shibu |first=K. |url=https://books.google.com/books?id=8hfn4gwR90MC&q=%22waiting+for+a+resource%22&pg=PA446 |publisher=Tata McGraw-Hill Education |year=2009 |title=Intro To Embedded Systems |edition=1st |page=446 |isbn=9780070145894 |access-date=16 October 2020 |archive-date=18 April 2021 |archive-url=https://web.archive.org/web/20210418013931/https://books.google.com/books?id=8hfn4gwR90MC&q=%22waiting+for+a+resource%22&pg=PA446 |url-status=live }}</ref>

These four conditions are known as the ''Coffman conditions'' from their first description in a 1971 article by [[Edward G. Coffman, Jr.]]<ref name="embb"/>

While these conditions are sufficient to produce a deadlock on single-instance resource systems, they only indicate the possibility of deadlock on systems having multiple instances of resources.<ref>{{Cite web|url=https://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/7_Deadlocks.html|title=Operating Systems: Deadlocks|website=www.cs.uic.edu|access-date=2020-04-25|quote=If a resource category contains more than one instance then the presence of a cycle in the resource-allocation graph indicates the possibility of a deadlock, but does not guarantee one. Consider, for example, Figures 7.3 and 7.4 below:|archive-date=28 May 2020|archive-url=https://web.archive.org/web/20200528052638/https://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/7_Deadlocks.html|url-status=live}}</ref>

==Deadlock handling==
Most current operating systems cannot prevent deadlocks.<ref>{{cite book|last=Silberschatz|first=Abraham|url=https://books.google.com/books?id=WjvX0HmVTlMC&q=deadlock+operating+systems|publisher=Wiley-India|year=2006|title=Operating System Principles|edition=7|page=237|isbn=9788126509621|access-date=16 October 2020|archive-date=18 April 2021|archive-url=https://web.archive.org/web/20210418013932/https://books.google.com/books?id=WjvX0HmVTlMC&q=deadlock+operating+systems|url-status=live}}</ref> When a deadlock occurs, different operating systems respond to them in different non-standard manners. Most approaches work by preventing one of the four ''Coffman conditions'' from occurring, especially the fourth one.<ref name=pric_os>{{cite book |last=Stuart |first=Brian L. |url=https://books.google.com/books?id=B5NC5-UfMMwC&q=coffman+conditions&pg=PA112 |publisher=Cengage Learning |year=2008 |title=Principles of operating systems |edition=1st |page=446 |isbn=9781418837693 |access-date=16 October 2020 |archive-date=18 April 2021 |archive-url=https://web.archive.org/web/20210418033945/https://books.google.com/books?id=B5NC5-UfMMwC&q=coffman+conditions&pg=PA112 |url-status=live }}</ref> Major approaches are as follows.

===Ignoring deadlock===
In this approach, it is assumed that a deadlock will never occur. This is also an application of the [[Ostrich algorithm]].<ref name="pric_os" /><ref name="distri_tanen">{{cite book |last=Tanenbaum |first=Andrew S. |url=https://books.google.com/books?id=l6sDRvKvCQ0C&q=Tanenbaum+ostrich&pg=PA177 |publisher=Pearson Education |year=1995 |title=Distributed Operating Systems |edition=1st |page=117 |isbn=9788177581799 |access-date=16 October 2020 |archive-date=18 April 2021 |archive-url=https://web.archive.org/web/20210418011235/https://books.google.com/books?id=l6sDRvKvCQ0C&q=Tanenbaum+ostrich&pg=PA177 |url-status=live }}</ref> This approach was initially used by [[MINIX]] and [[UNIX]].<ref name="embb"/> This is used when the time intervals between occurrences of deadlocks are large and the data loss incurred each time is tolerable.

Ignoring deadlocks can be safely done if deadlocks are [[formal verification|formally proven]] to never occur. An example is the RTIC framework.<ref>{{Cite web|url=https://rtic.rs/0.5/book/en/|title=Preface - Real-Time Interrupt-driven Concurrency|access-date=1 October 2020|archive-date=18 September 2020|archive-url=https://web.archive.org/web/20200918143731/https://rtic.rs/0.5/book/en/|url-status=live}}</ref>

===Detection===
Under the deadlock detection, deadlocks are allowed to occur. Then the state of the system is examined to detect that a deadlock has occurred and subsequently it is corrected. An algorithm is employed that tracks resource allocation and process states, it rolls back and restarts one or more of the processes in order to remove the detected deadlock. Detecting a deadlock that has already occurred is easily possible since the resources that each process has locked and/or currently requested are known to the [[Scheduler (computing)|resource scheduler]] of the operating system.<ref name=distri_tanen />

After a deadlock is detected, it can be corrected by using one of the following methods:{{Citation needed|date=May 2016}}
# ''Process termination:'' one or more processes involved in the deadlock may be aborted. One could choose to abort all competing [[Process (computing)|processes]] involved in the deadlock. This ensures that deadlock is resolved with certainty and speed.{{Citation needed|date=May 2016}} But the expense is high as partial computations will be lost. Or, one could choose to abort one process at a time until the deadlock is resolved. This approach has a high overhead because after each abort an algorithm must determine whether the system is still in deadlock.{{Citation needed|date=May 2016}} Several factors must be considered while choosing a candidate for termination, such as priority and age of the process.{{Citation needed|date=May 2016}}
# ''Resource preemption:'' resources allocated to various processes may be successively preempted and allocated to other processes until the deadlock is broken.<ref>{{cite web|url=https://www.ibm.com/support/knowledgecenter/SSETD4_9.1.2/lsf_admin/resource_preemption_about.html|title=IBM Knowledge Center|website=www.ibm.com|access-date=29 April 2018|url-status=live|archive-url=https://web.archive.org/web/20170319112925/https://www.ibm.com/support/knowledgecenter/SSETD4_9.1.2/lsf_admin/resource_preemption_about.html|archive-date=19 March 2017}}</ref>{{Failed verification|date=December 2021}}

===Prevention===
{{main|Deadlock prevention algorithms}}
[[File:Avoiding deadlock.gif|380px|thumbnail|right|
(A) Two processes competing for one resource, following a first-come, first-served policy.

(B) Deadlock occurs when both processes lock the resource simultaneously.

(C) The deadlock can be ''resolved'' by breaking the symmetry of the locks.

(D) The deadlock can be ''prevented'' by breaking the symmetry of the locking mechanism.]]
Deadlock prevention works by preventing one of the four Coffman conditions from occurring.
* Removing the ''mutual exclusion'' condition means that no process will have exclusive access to a resource. This proves impossible for resources that cannot be [[Spooling|spooled]]. But even with spooled resources, the deadlock could still occur. Algorithms that avoid mutual exclusion are called [[non-blocking synchronization]] algorithms.
* The ''hold and wait'' or ''resource holding'' conditions may be removed by requiring processes to request all the resources they will need before starting up (or before embarking upon a particular set of operations). This advance knowledge is frequently difficult to satisfy and, in any case, is an inefficient use of resources. Another way is to require processes to request resources only when it has none; First, they must release all their currently held resources before requesting all the resources they will need from scratch. This too is often impractical. It is so because resources may be allocated and remain unused for long periods. Also, a process requiring a popular resource may have to wait indefinitely, as such a resource may always be allocated to some process, resulting in [[resource starvation]].<ref>{{cite book|last=Silberschatz|first=Abraham|url=https://books.google.com/books?id=WjvX0HmVTlMC&q=deadlock+operating+systems|publisher=Wiley-India|year=2006|title=Operating System Principles|edition=7|page=244|isbn=9788126509621|access-date=16 October 2020|archive-date=18 April 2021|archive-url=https://web.archive.org/web/20210418013932/https://books.google.com/books?id=WjvX0HmVTlMC&q=deadlock+operating+systems|url-status=live}}</ref> (These algorithms, such as [[serializing tokens]], are known as the ''all-or-none algorithms''.)
* The ''no [[Preemption (computing)|preemption]]'' condition may also be difficult or impossible to avoid as a process has to be able to have a resource for a certain amount of time, or the processing outcome may be inconsistent or [[thrashing (computer science)|thrashing]] may occur. However, the inability to enforce preemption may interfere with a ''priority'' algorithm. Preemption of a "locked out" resource generally implies a [[Rollback (data management)|rollback]], and is to be avoided since it is very costly in overhead. Algorithms that allow preemption include [[lock-free and wait-free algorithms]] and [[optimistic concurrency control]]. If a process holding some resources and requests for some another resource(s) that cannot be immediately allocated to it, the condition may be removed by releasing all the currently being held resources of that process. 
* The final condition is the ''circular wait'' condition. Approaches that avoid circular waits include disabling interrupts during critical sections and using a hierarchy to determine a [[partial order]]ing of resources. If no obvious hierarchy exists, even the memory address of resources has been used to determine ordering and resources are requested in the increasing order of the enumeration.<ref name="os_galvin"/> [[Dining philosophers problem#Resource hierarchy solution|Dijkstra's solution]] can also be used.

===Deadlock avoidance===
Similar to deadlock prevention, deadlock avoidance approach ensures that deadlock will not occur in a system. The term "deadlock avoidance" appears to be very close to "deadlock prevention" in a linguistic context, but they are very much different in the context of deadlock handling. Deadlock avoidance does not impose any conditions as seen in prevention but, here each resource request is carefully analyzed to see whether it could be safely fulfilled without causing deadlock.

Deadlock avoidance requires that the operating system be given in advance additional information concerning which resources a process will request and use during its lifetime. Deadlock avoidance algorithm analyzes each and every request by examining that there is no possibility of deadlock occurrence in the future if the requested resource is allocated. The drawback of this approach is its requirement of information in advance about how resources are to be requested in the future. One of the most used deadlock avoidance algorithms is [[Banker's algorithm]].<ref>{{Cite web|url=https://www.electronicsmind.com/2022/01/deadlock-avoidance-algorithms-in-operating-system.html|title=Deadlock Avoidance Algorithms in Operating System (OS)|date=26 January 2022|website=Electronics Mind}}</ref>

== Livelock ==
{{redirect|Livelock|the video game|Livelock (video game)}}
A ''livelock'' is similar to a deadlock, except that the states of the processes involved in the livelock constantly change with regard to one another, none progressing.

The term was coined by [[Edward A. Ashcroft]] in a 1975 paper<ref>{{cite journal|title=Proving assertions about parallel programs|journal=Journal of Computer and System Sciences|volume=10|pages=110–135|doi=10.1016/S0022-0000(75)80018-3|year=1975|last1=Ashcroft|first1=E.A.|doi-access=free}}</ref> in connection with an examination of airline booking systems.<ref>{{cite book|chapter=On the absence of livelocks in parallel programs|doi=10.1007/BFb0022469|title=Semantics of Concurrent Computation|volume=70|pages=172–190|series=Lecture Notes in Computer Science|year=1979|last1=Kwong|first1=Y. S.|isbn=3-540-09511-X}}</ref> Livelock is a special case of [[resource starvation]]; the general definition only states that a specific process is not progressing.<ref>{{cite web|url=http://citeseer.ist.psu.edu/anderson01sharedmemory.html|first=James H.|last=Anderson|author1-link=James H. Anderson (computer scientist)|author2=Yong-jik Kim|title=Shared-memory mutual exclusion: Major research trends since 1986|year=2001|url-status=live|archive-url=https://web.archive.org/web/20060525013335/http://citeseer.ist.psu.edu/anderson01sharedmemory.html|archive-date=25 May 2006}}</ref>

Livelock is a risk with some [[algorithm]]s that detect and recover from ''deadlock''. If more than one process takes action, the [[deadlock detection algorithm]] can be repeatedly triggered. This can be avoided by ensuring that only one process (chosen arbitrarily or by priority) takes action.<ref>{{cite journal|doi=10.1145/850752.850753 |title=The Deadlock problem: a classifying bibliography | first = Dieter |last = Zöbel | journal = ACM SIGOPS Operating Systems Review |volume=17 |issue=4 |date=October 1983 |issn=0163-5980 |pages = 6–15|s2cid=38901737 |doi-access=free }}</ref>

==Distributed deadlock==
''Distributed deadlocks'' can occur in [[distributed systems]] when [[distributed transaction]]s or [[concurrency control]] is being used.

Distributed deadlocks can be detected either by constructing a global [[wait-for graph]] from local wait-for graphs at a deadlock detector or by a [[distributed algorithm]] like edge chasing.

''Phantom deadlocks'' are deadlocks that are falsely detected in a distributed system due to system internal delays but do not actually exist. For example, if a process releases a resource ''R1'' and issues a request for ''R2'', and the first message is lost or delayed, a coordinator (detector of deadlocks) could falsely conclude a deadlock (if the request for ''R2'' while having ''R1'' would cause a deadlock).

==See also==
{{div col|colwidth=20em}}
* [[Aporia]]
* [[Banker's algorithm]]
* [[Catch-22 (logic)]]
* [[Circular reference]]
* [[Dining philosophers problem]]
* [[File locking]]
* [[Gridlock]] (in vehicular traffic)
* [[Hang (computing)]]
* [[Impasse]]
* [[Infinite loop]]
* [[Linearizability]]
* [[Model checker]] can be used to formally verify that a system will never enter a deadlock
* [[Ostrich algorithm]]
* [[Priority inversion]]
* [[Race condition]]
* [[Readers-writer lock]]
* [[Sleeping barber problem]]
* [[Stalemate]]
* [[Synchronization (computer science)]]
* [[Turn restriction routing]]
{{div col end}}

==References==
{{reflist}}

==Further reading==
* {{cite journal|title=Deadlock Detection in Distributed Object Systems|publisher=University College London|location=London|url=http://www.cs.ucl.ac.uk/staff/w.emmerich/publications/ESEC01/ModelChecking/esec.pdf|first1=Nima|last1=Kaveh|first2=Wolfgang|last2=Emmerich}}
* {{cite book|last1=Bensalem|first1=Saddek|first2=Jean-Claude|last2=Fernandez|first3=Klaus|last3=Havelund|first4=Laurent|last4=Mounier|title=Proceedings of the 2006 workshop on Parallel and distributed systems: Testing and debugging |chapter=Confirmation of deadlock potentials detected by runtime analysis |year=2006|publisher=ACM|pages=41–50|doi=10.1145/1147403.1147412|isbn=978-1595934147|citeseerx=10.1.1.431.3757|s2cid=2544690}}
* {{cite journal|doi=10.1145/356586.356588|year=1971|title=System Deadlocks|journal=ACM Computing Surveys|volume=3|issue=2|pages=67–78|url=http://www.cs.umass.edu/~mcorner/courses/691J/papers/TS/coffman_deadlocks/coffman_deadlocks.pdf|last1=Coffman|first1=Edward G. Jr. |first2=Michael J.| last2=Elphick|first3=Arie|last3=Shoshani|s2cid=15975305}}
* {{cite journal|last1=Mogul|first1=Jeffrey C.|first2=K.<!-- Koneru? --> K.|last2=Ramakrishnan|year=1997|title=Eliminating receive livelock in an interrupt-driven kernel|journal=ACM Transactions on Computer Systems|volume=15|issue=3|pages=217–252|issn=0734-2071|doi=10.1145/263326.263335|citeseerx=10.1.1.156.667|s2cid=215749380}}
* {{cite journal|last=Havender|first=James W.|year=1968|title=Avoiding deadlock in multitasking systems|journal=IBM Systems Journal|volume=7|issue=2|page=74|url=http://domino.research.ibm.com/tchjr/journalindex.nsf/a3807c5b4823c53f85256561006324be/c014b699abf7b9ea85256bfa00685a38?OpenDocument|doi=10.1147/sj.72.0074|access-date=27 January 2009|archive-date=24 February 2012|archive-url=https://web.archive.org/web/20120224124105/http://domino.research.ibm.com/tchjr/journalindex.nsf/a3807c5b4823c53f85256561006324be/c014b699abf7b9ea85256bfa00685a38?OpenDocument|url-status=dead|url-access=subscription}}
* {{cite journal|journal=Encyclopedia of Distributed Computing|url=http://www.cse.scu.edu/~jholliday/dd_9_16.htm|title=Distributed Deadlock Detection|first1=JoAnne L.|last1=Holliday|first2=Amr|last2=El Abbadi|access-date=29 December 2004|archive-url=https://web.archive.org/web/20151102065120/http://www.cse.scu.edu/~jholliday/dd_9_16.htm|archive-date=2 November 2015|url-status=dead}}
* {{cite journal|last=Knapp|first=Edgar|year=1987|title=Deadlock detection in distributed databases| journal=ACM Computing Surveys|volume=19|issue=4|pages=303–328|issn=0360-0300|doi=10.1145/45075.46163|citeseerx=10.1.1.137.6874|s2cid=2353246}}
* {{cite journal|last1=Ling|first1=Yibei|last2=Chen|first2=Shigang|last3=Chiang|first3=Jason|year=2006|title=On Optimal Deadlock Detection Scheduling|journal=IEEE Transactions on Computers|volume=55|issue=9|pages=1178–1187|doi=10.1109/tc.2006.151|citeseerx=10.1.1.259.4311|s2cid=7813284}}

==External links==
* "[http://www.onjava.com/pub/a/onjava/2004/10/20/threads2.html Advanced Synchronization in Java Threads]" by Scott Oaks and Henry Wong
* [https://web.archive.org/web/20050504052535/http://www-db.in.tum.de/research/projects/dda.html Deadlock Detection Agents]
* [[c2:DeadLock|DeadLock]] at the Portland Pattern Repository
* [http://www.etymonline.com/index.php?term=deadlock Etymology of "Deadlock"]

{{Concurrent computing}}
{{authority control}}

[[Category:Concurrency (computer science)]]
[[Category:Software bugs]]
[[Category:Software anomalies]]
[[Category:Distributed computing problems]]