-1

Following is a specific case of a deadlock:

There are 2 threads-- T0 & T1, and 2 resources-- R0 & R1.

T0 is holding the lock of R0 & waiting to access R1 to release R0. T1 is doing the same the other way round-- holding R1 & waiting for R0.

A way to resolve this that I can think of:

After a certain time of wait-- which supposedly indicates this infinite loop, Tx, x=0 or 1, writes the state of Rx to an object Ox and sets a flag Fx that it is done with updating Rx. It also checks the flag F(1-x) to see whether it is set-- if so, reads the state from O(1-x), proceeds accordingly & releases Rx. In this scenario, T0 & T1 are prioritized (Thread class of Java has means to prioritize threads(?), or this can be achieved by a class instance-- one of the threads created with a specific value on a static variable is taking charge in breaking this loop.)

This works if T(1-x)'s further execution on R(1-x) upon acquiring Rx doesn't alter the state of R(1-x).

What is wrong with this scenario?

Is there another/better way to handle this?

I'm aware of managing the access to resources in an ordered fashion as pointed out in many articles.

Roam
  • 4,831
  • 9
  • 43
  • 72

1 Answers1

1

What is wrong with this scenario?

Under normal circumstances the two threads will be blocked when they try to acquire the lock. (If they are using primitive locks (i.e. synchronized) then there's no way to avoid this.) While the threads are blocked, they cannot do things to detect the deadlock.

Alternatively, if you are using something like Lock.tryLock(long time, TimeUnit unit) then the threads are not actually deadlocked. What you have is a live-lock, where the threads are blindly retrying the tryLock after each timeout. The fix for that is to not retry. If the tryLock call times out, treat it as an error.

Is there another/better way to handle this?

You can use ThreadMXBean to detect deadlocked threads. See https://stackoverflow.com/a/1102410/139985 for details. Obviously, you have to do this on another thread ... not on the threads that are prone to deadlocking!

(I found this by Googling for "Java deadlock detection" ... and reading the answers.)

Community
  • 1
  • 1
Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • Thanks for the ans-- i'll look up Lock.tryLock(..). i'm also wondering with what-- if anything is wrong with my scenario up in the Q. – Roam Oct 20 '13 at 01:51
  • @Roam - to be clear, if you use `tryLock` (correctly) you are *avoiding* the deadlock rather than detecting it. If you use it incorrectly, you are replacing deadlock with livelock. A better option is to find the root cause of the deadlocks and fix it. – Stephen C Oct 20 '13 at 01:55
  • Stephen C: this answers part of my Q. so again-- WHAT's wrong with my solution??? – Roam Oct 20 '13 at 02:11
  • @Roam - express it as Java code, and I'll take a look at it. And don't neglect to show how your algorithm integrates with the code that is acquiring the lock. – Stephen C Oct 20 '13 at 03:10
  • Stephen C: it wd be for JVM to answers those – Roam Oct 20 '13 at 19:02
  • @Roam - if you are asking for commentary on a *hypothetical* way of doing deadlock detection in the JVM's locking primitives, my response is 1) show me your proposed C++ code, and 2) it is pretty much irrelevant because a JVM *shouldn't* and *wouldn't* do deadlock detection in its implementation of the locking primitives. – Stephen C Oct 21 '13 at 07:49
  • Either way, I'm not going to comment on your algorithm unless you show me expressed as concrete code. Your presentation of the algorithm in English is too unclear to understand. – Stephen C Oct 21 '13 at 07:51