Talk:Deadlock

message: Deadlock, in the abstract sense, is just a group of member waiting for each other to do some thing. That thing might be anything, sending a message, releasing a resource, a series of events occurring in a specific order.
Deadlock, therefore, has *little* to do with locks. Locks are just one manner of not being able to access a resource. The book referenced in the introduction *falsely* narrows this common definition to locked resources only, which is what that book likely is about, but has nothing to do with this phenomenon in the abstract sense.
Deadlock can always be abstractly modeled into *any* system which allows for concurrently communicating processes to be modeled, independent of the means of communication. Process A waiting for process B to send a message, and process B waiting for process A to send a message, is enough.  — Preceding unsigned comment added by 86.82.44.193 (talk) 01:38, 11 August 2017 (UTC)
thread_title: Confusion about locks

message: Shouldn't this article have the term "Deadly Embrace" somewhere in it as an alternate term for Deadlock? --grr 23:12, 12 December 2006 (UTC)
replies: text: ...No? Lx45803 (talk) 04:42, 28 January 2009 (UTC)

text: Why, "Definitely not?" Software developers from England with whom I have worked said "deadly embrace" more often than they said "deadlock." Also, I'm sure I have read at least one book whose author thought that "deadly embrace" was the special case of a deadlock between just two processes/threads/etc. 74.111.96.172 (talk) 14:31, 5 March 2022 (UTC)
thread_title: Deadly embrace?

message: :An example of a deadlock occurs frequently in database products. Client applications using the database may require exclusive access to a given table, and in order to gain exclusive access they ask for a lock. If two client applications both attempt to lock the same table at the same time, neither will receive it, there is no general way to decide who to give the lock to. In this case both clients will wait for the lock forever.
Um, no.  Just give it to one of the clients which will run and finish, then the other one gets a chance to run.  I'm giong to replace this with a better example MatthewWilcox 12:55, 15 Dec 2004 (UTC)
replies: text: (But this particular type of deadlock is easily prevented, e.g., by using an all-or-none resource allocation algorithm.)
are you proposing something like LOCK table_1, table_2 IN EXCLUSIVE MODE; at the beginning of the transaction? That severely limits concurrency. I'd say it's better to use a per-row example like the PostgreSQL one and suggest resolving it application-side in one of two ways:
* using a consistent ordering
* catch the "would deadlock" exception generated by the database server and replay the transaction
- Slamb 20:37, 20 August 2006 (UTC)
thread_title: Poor examples

message: Seems to me the term "deadlock" doesn't apply primarily to computing. The more general term 'deadlock' meaning any stalemate situation is probably more deserving of the article title, as long as it doesn't end up being just a dicdef. The other meaning of deadlock - a type of mechanical lock mechanism - should also go somewhere, I think. Should this be moved to Deadlock (computing) leaving the main title for a disambiguation page? Graham 11:52, 7 October 2005 (UTC)
replies: text: Deadlock is a problem in software systems far more often than in any other system. Software can be many orders of magnitude more complex than any other human creation, and that complexity makes it more likely that the designers accidentally build a system that is prone to it. Also, in any system in which humans play a role, if a deadlock does occur, the human agents usually recognize the problem and they find a way around it (i.e., they break the rules of the system). Software, of course, can never break its own rules. 74.111.96.172 (talk) 14:46, 5 March 2022 (UTC)
thread_title: Article naming

message: The article said:
Instead deadlock detection and clean up is used by employing an algorithm that tracks the circular waiting and kills one or more of the processes such that the deadlock is removed.
This problem is undecidable in general, because the halting problem can be rephrased as a deadlock scenario.
This is not true, or at least confusing. Detecting a deadlock that has already happened is, given sufficient information about actors (threads, clients etc.) and the resources they have locked and requested in a blocking manner, simple. Telling whether a given program will or may cause deadlocks, on the other hand, is very hard, and in general undecidable.
Or, if that explanation doesn't suffice: Imagine a program that controls train traffic. When it contains a bad bug, trains may crash into one another. When a train wreck happens in this way, it's easy to detect: Just follow the smoke and the trail of ambulances. ;-) However, telling whether execution of the program may lead to a train crash before a train crash actually occurred is difficult (undecidable) in the general case. What people usually do in order to be sure is to write the program in such a way that its correctness (impossibility of train crashes) can be proven. This of course requires adherence to a subset of possible programs, since not all correct programs can be proven to be correct (-> Gödel's incompleteness theorem). Aragorn2 18:36, 16 March 2006 (UTC)
thread_title:  Decidability of Deadlock Detection 

message: Should this article be merged with the preemption (computing) and circular wait articles?  (There is no hold-and-wait page, and the mutual_exclusion page probably contains enough information to be seperated.)  Another possibility would be to make a seperate page for Coffman conditions and merge preemption, circular wait and mutual exclusion with that.  MagiMaster 08:47, 10 July 2006 (UTC)
thread_title:  Merge? 

message: I'm quite confused by the following sections, which seem to be primarily discussing:
* Deadlock avoidance - resource manager detecting potential deadlock and raising error
* Deadlock prevention - resource consumer avoiding deadlock in the first place
* Deadlock detection - (1) resource manager/consumer post-detection rollback process, (2) static verification that a consumer is deadlock-free
I'd like to explicitly mention that there are often two players involved - the manager (perhaps a kernel or RDBMS) and the consumer (application), and then break them apart into:
* Deadlock avoidance - consumer avoiding deadlock in the first place, passing mention of static verification
* Deadlock detection - manager detecting deadlock as it happens
* Deadlock recovery - consumer/manager rollback process
and keep the roles clear in the writing of each section. Comments? Agree/disagree? -Slamb 21:37, 20 August 2006 (UTC)
thread_title:  Organization 

message: I think many developers have the misconception that "resource" = "mutex", and that's not necessarily true. I'd like to add counterexamples to the page. I'm trying to avoid original research, though. Are there good citable examples around?
Here's a situation that came up in my own work:
# My Python graphing program writes to a gnuplot control pipe.
# gnuplot writes a bunch of stupid warnings to stderr, a pipe back to my Python graphing program.
# gnuplot blocks at PIPEBUF bytes, waiting for my program to consume them.
# My program blocks at PIPEBUF bytes, waiting for gnuplot to consume them.
# Deadlock.
I think it's a good counterexample. No locks involved and furthermore, the program that acquires a release isn't even the one expected to release it! The solution is also interesting - I essentially removed one of the shared resources by making gnuplot write to a temporary file, which my program examines after the fact.
Another neglected situation is a deadlock where a single context of execution has both resources and is waiting for itself. This can sometimes happen in asynchronous designs. I can come up with an example of this, but again it'd be from my own work, not something citable. -Slamb 21:56, 20 August 2006 (UTC)
thread_title:  Neglected deadlock situations 

message: In the table in the section Deadlock#Avoidance, I suspect (by symmetry) that the top right cell should say "O dies" rather than "Y dies". However I'm not sure the table adds anything that couldn't be better provided by another sentence or two of explanation - are these two strategies simply "when the OS detects that a resource request would cause a deadlock, it kills (in one case) the oldest, and (in the other case) the youngest of the processes involved in the cycle"? Hv (talk) 21:40, 14 July 2008 (UTC)
thread_title:  Y dies? 

message: The original paper "Eliminating Receive Livelock in an Interrupt-driven Kernel" by Mogul, Jeffrey C., K. K. Ramakrishnan was published in 1995 and not in 2007. Do they have an update in 2007?  —Preceding unsigned comment added by 208.51.227.50 (talk) 15:04, 4 August 2009 (UTC)
thread_title:  Possible wrong year for a reference 

message: To ensure that the hold-and-wait condition never occurs in the system,we must guarantee that,whenever a process requests a resource, it does not hold any other resources.One protocol that can be used requires each process to request and be allocated all its resources before it begins execution.We can implement this provision by requiring that system calls requesting resources for a process precede all other system calls.An alternative protocol allows a process to request resources only when the process has none.A process may request some resources and use them.Before it can request any additional resources, however,it must release all the resources that it is currently allocated.Operating System Concepts,fourth edition;Abraham Silberschatz and Peter B.Galvin  —Preceding unsigned comment added by Sth.pratik (talk • contribs) 11:00, 10 December 2009 (UTC)
thread_title:  Hold and Wait 

message: "Phantom deadlocks are deadlocks that are detected in a distributed system due to system internal delays, but no longer actually exist at the time of detection. deadlock prevents devices to stop functions."
First, if there is no more deadlock, i.e. the deadlock was resolved without the help of a detection/resolution mechanism, doesn't that imply that there was no deadlock, just a delay? 
And secondly, that last sentence makes no sense, and I can't figure out what it's supposed to mean, so I'm going to remove it. Please someone put it back in (corrected) if you know what that is supposed to say. Chaos.squirrel (talk) 07:13, 23 June 2010 (UTC)
thread_title:  Phantom deadlocks 

message: My understanding is that deadlocks can only happen through explicit locking.  If they happen outside of locking, they need to be called by a different term which does not have the word "lock" in it.  This is very confusing if they are grouped together.
Does anyone have an idea what to call this term?  And does it already exist?
Also, is there a difference between hard-locks and deadlocks?  Or is the term hard-lock a made up term?
:No, deadlock is a general term and even defined in dictionaries as a state where no progress is made by any party (because they are waiting for something to happen). "The game ended in a deadlock 1-1 result." It has little to do with locks in the general sense.  — Preceding unsigned comment added by 86.82.44.193 (talk) 01:54, 11 August 2017 (UTC)
thread_title: Deadlocking Without Locking?

message: "Detecting the possibility of a deadlock before it occurs is much more difficult and is, in fact, generally undecidable, because the halting problem can be rephrased as a deadlock scenario."
This is misleading because it gives the impression that within the locking mechanism, we have no control over the condition in which halting occurs.  The Halting problem states, "The proof shows there is no total computable function that decides whether an arbitrary program i halts on arbitrary input x."
Distributed deadlock prevention within the article shows that the halting issue and locking are mutually exclusive, because all conditions within it are known.  It would be valid to re-defining the halting problem in terms of locking, but this requires locking to use unknown/arbitrary conditions. Though I guess this is valid, it is not logical as to why anyone would want to intentionally do this.
;Quote
"If I shook a magic 8 ball with digital text that I could change after seeing the initial answer, I believe that "without-a-doubt, all signs point to yes" (given I had the room to write that)." -- TamusJRoyce (please re-quote if I heard it/similar elsewhere and I don't remember it).
TamusJRoyce (talk) 01:17, 30 September 2010 (UTC)
thread_title: Misconception

message: In the article's examples section I see that there are currently constructions like:
"(there is, but until this is edited otherwise, assume there isn't until reading Distributed deadlock prevention)"
and
"I believe Preemption_(computing) is the term being looked for here?"
Shouldn't self referential statement about the article or comments about what edits need to be made go into the talk page rather than the text of the article itself? It seems out of place in an encyclopedia.
Jbpayton (talk) 18:36, 14 October 2010 (UTC)
thread_title:  Wording in Example Section 

message: The article has inconsistent use of "Process" and "Thread" - the Distributed deadlock section of the article uses the term "Thread", whereas the rest of the article uses the term "Process".  Unless "Process" has some alternative meaning in this context (that is not described in this article), then I believe "Thread" is the more accurate term to use.  --Kragen2uk (talk) 23:44, 12 January 2011 (UTC)
thread_title:  Thread vs Process 

message: This sentence "Computers intended for the time-sharing and/or real-time markets are often equipped with a hardware lock (or hard lock) which guarantees exclusive access to processes, forcing serialized access." has nothing whatsoever to do with deadlocks.  It's evidently some kind of misconception by the author that locking is related to deadlocking and it's not really.  I'm going to remove this sentence in the next week or so unless someone can tell me exactly how hardware locking is related to deadlocking. Wjhonson (talk) 17:01, 25 October 2011 (UTC)
thread_title:  Hardware lock 

message: The neutrality of part of this page is disputed, as part of a wider discussion. See Talk:Commitment ordering and Wikipedia talk:WikiProject Computer science#User:Comps / Commitment ordering. —Ruud 14:27, 23 December 2011 (UTC)
thread_title:  Commitment ordering 

message: Changes made:
* Header rewritten and rephrased
* Uncited info deleted from header (related to real-time systems and hardware locks)
* Citations added for deadlock and telecommunication deadlock definitions.
* Citations added for examples (chicken and egg, and catch-22)
* Conditions expanded
* Citations added for Coffman conditions.
* Subsections regarding Deadlock Handling restructured and rephrased. Citations added.
* Ignoring Deadlocks subsection added. Citations added.
Tyler.norton12 00:01, 29 January 2012 (UTC)
thread_title: Article Rewrite (29 Jan, 2012)

message: For:
*Even though most classical deadlock handling techniques can be extended to Distributed Systems, distributed deadlocks are a vast and more complex concept. They involved methods like edge-chasing algorithms, probe-based algorithms, etc. It is a more advanced and newer field compared to deadlocks in simpler multiprocessing systems. Tyler.norton12 00:08, 29 January 2012 (UTC)
thread_title: Suggestion: Splitting Section "Distributed Deadlocks" into new page

message: The translation to Denmark is the wrong.. It has nothing todo with computer "deadlock".  — Preceding unsigned comment added by 87.55.62.15 (talk) 21:14, 20 May 2012 (UTC)
thread_title:  Danish translation 

message: The current text says: "In a commitment ordering-based distributed environment (including the strong strict two-phase locking (SS2PL, or rigorous) special case) distributed deadlocks are resolved automatically by the atomic commitment protocol (like a two-phase commit (2PC)), and no global wait-for graph or other resolution mechanism is needed. Similar automatic global deadlock resolution occurs also in environments that employ 2PL that is not SS2PL (and typically not CO; see Deadlocks in 2PL)."
WHAT!??? this is complete rubbish! 
1. 2PC (2 Phase COMMIT) can definitely not prevent deadlocks! It is used to guarantee atomicity! The deadlock occurs before a transaction decides to commit - before 2PC even starts. Distributed 2PC can actually cause a blocking situation, when a subtransaction has precommitted and is waiting for the global commit-decision (in-doubt-transaction). This, however, is not a deadlock.
2. 2PL will not automatically prevent deadlocks! In contrast: It is the reason for deadlocks!! 2PL guarantees serializable histories at the risk of deadlocks. Preclaiming could actually prevent deadlocks (request all locks at the beginning). Strict locking (Hold all locks until the end) has nothing to to with deadlocks! It guarantees recoverability, avoids cascading aborts and allows undoing a transactions updates by using before-images.  — Preceding unsigned comment added by 84.147.184.89 (talk) 20:14, 26 May 2014 (UTC)
thread_title:  Wrong statements 

message: "That and the use of the strong word "dead" in front of lock are some of the reasons why deadlocks have a "this is a big problem" reputation." 
I would personally like to eliminate that sentence altogether - the section and paragraph were not about the "reputation" of deadlocks. It sounds like this translates to "...and it has a scary name, which is why you should be afraid of it." Does the sentence serve a purpose I'm missing?
Sobeita (talk) 02:33, 24 September 2014 (UTC)
thread_title:  Sudden change of tone / subject? 

message: Hello fellow Wikipedians,
I have just modified one external link on Deadlock. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20050504052535/http://www-db.in.tum.de/research/projects/dda.html to http://www-db.in.tum.de/research/projects/dda.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 04:39, 6 December 2017 (UTC)
thread_title:  External links modified