Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Is there a way to detect and break the deadlock  RSS feed

 
Om Tejas
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

Deadlock is very common in Java. Is there a way to break the deadlock using any APIs.
 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Deadlock is very common in Java.

That's news to me. What are you basing this statement on?

Deadlocks don't occur for a particular language, they occur for particular code. Are you talking about specific code that exhibits deadlocks?
 
Om Tejas
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 way to avoid deadlocks is not to write code that exhibits http://en.wikipedia.org/wiki/Deadlock#Necessary_conditions. This is true for all code running in multi-threaded environments, irrespective of the language it's written in.
 
Om Tejas
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Stephan van Hulst
Saloon Keeper
Posts: 7716
141
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not within the same program, or it wouldn't be deadlock.
 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Henry Wong
author
Sheriff
Posts: 23275
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.

Henry
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!