Yes for a specific code. For example when using java threads.
If I am not wrong, the above is a potential deadlock scenario. Is there a way to break this deadlock, apart from Ctrl+c etc. Any APIs
Joined: Mar 22, 2005
Not sure how you think a deadlock could occur, given that the threads synchronize on different objects. If the code in processB synchronized on A.class, and vice-versa, then you'd have a potential deadlock:
The link and wiki gives information on necessary condition, prevention, avoidance and detection. My question what to do after deadlock is dectected. I have come across some articles which say that ThreadMxBean can be used to detect the deadlock threads. What I am trying to find out is there a way to move the threads in deadlock out of deadlock state once deadlock is detected.
Not within the same program, or it wouldn't be deadlock.
Joined: Mar 22, 2005
Stephan van Hulst wrote:Not within the same program, or it wouldn't be deadlock.
There could still be live threads, even if some other ones are deadlocked.
Killing threads and then resuming execution would be dangerous, as the application could be in an instable or inconsistent state (see the explanation of the Thread.destroy() method). Some high-end databases can detect deadlocks, select one thread for termination and let the others proceed, but that's a special case as the app can tell exactly what a thread is doing (by looking at the SQL it executes).
Joined: Mar 05, 2008
If the threads involved are each using the synchronized keyword to lock on (or attempt to lock on) the various monitors involved, then once deadlock occurs, there's no way out other than maybe Thread.destroy(), as Ulf said.
However, since JDK 5 it's been possible to use java.util.concurrent.locks.Lock instead of the synchronized keyword. The resulting code is more verbose but has many more options for handling locks. In particular, if you never use the lock() method, but instead use lockInterruptibly() or tryLock(), then it becomes possible to write code that gets out of a prospective deadlock. Which technically means it wasn't a deadlock if you can get out of it. But you can get out of situations that would have otherwise been deadlocks if using synchronization. Writing such code would still be rather complex; I don't have a ready quick example. But at least it's possible.
Oh, and java.util.concurrent.locks.ReentrantLock has additional methods that could be useful. Things like getOwner(), getQueuedThreads(), isLocked(), isHeldByCurrentThread(), etc. Lots of possibilities there.
Generally, deadlocks are avoided, instead of "detected and broken". Even if deadlock detection is simple (and it isn't), the task of undoing what you did so far isn't easy. In order to break a deadlock, you need to undo operations, which means that you need to support some sort of transaction system -- which requires that databases, and everything you use, support transactions too.
And the most common way to avoid deadlocks is to establish a locking hierarchy -- when lots of related locks are needed, locks need to be grabbed in a certain order. It makes it much more coarse, but it will avoid deadlocks.