aspose file tools*
The moose likes Threads and Synchronization and the fly likes How to avoid Deadlock  (Wait with two locks) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "How to avoid Deadlock  (Wait with two locks)" Watch "How to avoid Deadlock  (Wait with two locks)" New topic
Author

How to avoid Deadlock (Wait with two locks)

Krishna Kumar S
Greenhorn

Joined: Jan 31, 2012
Posts: 12
Class XXX{
boolean readyToRead = false;
public synchronized void demo(){
//do some initialization
synchronized(obj){
if(readyToRead){
obj.wait()
}

if(some other condition){
readyToRead = true;
obj.notifyAll();
}
}
}
}


the problem is when the code waits it wait with the instance lock of the class XXX. so some other thread which has to notify the waiting thread need this lock to proceed further. so i'm suspecting deadlock. could anyone suggest me how i should avoid deadlock in inter thread communication? Thanks a lot.
Anayonkar Shivalkar
Bartender

Joined: Dec 08, 2010
Posts: 1512
    
    5

Hi Krishna Kumar S,

Welcome to coderanch!

Krishna Kumar S wrote: the problem is when the code waits it wait with the instance lock of the class XXX.

This is the confusion. If you check official documentation of wait method, you'll find:
The current thread must own this object's monitor. The thread releases ownership of this monitor and waits until another thread notifies threads waiting on this object's monitor to wake up either through a call to the notify method or the notifyAll method. The thread then waits until it can re-obtain ownership of the monitor and resumes execution.

So, basically, it happens as below:
1) Thread 1 obtains lock on obj.
2) Thread 1 waits on obj, which means, Thread 1 has now given up lock on obj.
3) Now, Thread 2 obtains lock on obj, does some stuff and calls notify.
4) Lets assume that notify from Thread 2 will awake Thread 1 (thread to be awakened will be chosen arbitrarily). Now, Thread 1 awakes, and want to proceed execution, but it has already given up the lock. Thread 1 must obtain the lock again.
5) Meanwhile, Thread 2 proceeds, gets out of synchronized block and hence gives up lock.
6) Now, Thread 1 acquires the lock, and proceeds.

I hope this helps.


Regards,
Anayonkar Shivalkar (SCJP, SCWCD, OCMJD, OCEEJBD)
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Krishna Kumar S wrote:could anyone suggest me how i should avoid deadlock


By making sure that everywhere you acquire multiple locks, you acquire them in the same order.

It's not clear to me why you even need two locks here.
Krishna Kumar S
Greenhorn

Joined: Jan 31, 2012
Posts: 12
Thanks guys ...

Because of the bad design it was in deadlock. Now got them resolved.

Lesson learnt: Do not let the thread to hold the lock and gets into wait state.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Krishna Kumar S wrote:
Lesson learnt: Do not let the thread to hold the lock and gets into wait state.


No, it's perfectly acceptable for a thread to hold a lock and call wait(). Threads have to hold locks. It's the only way to provide mutual exclusion. And you can only call wait() on an object when you're holding that object's lock.

The real lesson is that when acquiring multiple locks, make sure that all threads acquire those locks in the same order.

If all you did to "fix" this was to get rid of sync blocks, then you may have severely broken your code. If you need syncing and wait(), you need it, and if you're having deadlock problems, the solution isn't to get rid of it; the solution is to use it correctly.
Krishna Kumar S
Greenhorn

Joined: Jan 31, 2012
Posts: 12
Hi Jeff. Thanks and Sorry for the late reply.

As per your statement,
"The real lesson is that when acquiring multiple locks, make sure that all threads acquire those locks in the same order. "
But i could see problem even when following this.

Say There is thread safe model (MVC pattern) which will be accessed by two Threads (T1 and T2). similarly both threads are using object (say obj) for inter thread communication (wait-notifyall).
The order to acquire the lock is defined (first to acquire model then to acquire obj).

Deadlock scenario:

If T1 acquires the model lock and subsequently acquires obj lock. Then T1 wait on obj and holds the lock of model. T1 will come out of waiting state only when T2 notifies it.
T2 cannot notify T1 as to proceed further it need the lock of model. and hence deadlock.
Martin Vajsar
Sheriff

Joined: Aug 22, 2010
Posts: 3611
    
  60

Krishna Kumar S wrote:Say There is thread safe model (MVC pattern) which will be accessed by two Threads (T1 and T2). similarly both threads are using object (say obj) for inter thread communication (wait-notifyall).
The order to acquire the lock is defined (first to acquire model then to acquire obj).

Deadlock scenario:

If T1 acquires the model lock and subsequently acquires obj lock. Then T1 wait on obj and holds the lock of model. T1 will come out of waiting state only when T2 notifies it.
T2 cannot notify T1 as to proceed further it need the lock of model. and hence deadlock.

Yes, this is true, but why should you hold the model lock while waiting? The reason to hold locks is to prevent other threads from interfering with operations you're currently performing. As you obviously cannot perform any operation while you wait, keeping a lock while waiting does not make much sense.
Krishna Kumar S
Greenhorn

Joined: Jan 31, 2012
Posts: 12
Yeah that's why i posted lesson learnt as "Do not let the thread to hold multiple locks and gets into wait state."
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How to avoid Deadlock (Wait with two locks)