6/13/13

Blocked vs Waiting Thread (Threads forum at JavaRanch)

File APIs for Java Developers Manipulate DOC, XLS, PPT, PDF and many others from your application. http://aspose.com/file-tools

Big Moose Saloon

A friendly place for programming greenhorns!
Search

Java FAQ

Recent Topics

Register / Login

A special promo: Enter your blog post or vote on a blogger to be featured in an upcoming Journal

JavaRanch Java Forums Java Threads and Synchronization

Author

Blocked vs Waiting Thread

posted 1/11/2009 2:04:54 PM

Alain Dickson Ranch Hand Joined: Dec 08, 2008 Posts: 53

Hi Ranches, need your help to clear a point, Is there a difference in Thread's state when it encouters following two situations. I have question about Blocked state. Here is how I understand the two states. 1.(WAITING). The thread enters synchronized block and calls wait() on the object whos lock it already have and waits till some other thread notify it. 2(BLOCKED). The Thread makes a calls to synchronized method whos lock is already acquired by some other thread and gets blocked. Question : Once a thread is blocked, does it wait quietly for someone Or some event to tell him that the lock is available(just like wait/notify) OR it keeps on trying it until it gets lock. Many thanks, Alain

www.coderanch.com/t/425685/threads/java/Blocked-Waiting-Thread

1/5

6/13/13

Blocked vs Waiting Thread (Threads forum at JavaRanch)

Mike Simmons Ranch Hand Joined: Mar 05, 2008 Posts: 2802

posted 1/11/2009 9:52:13 PM

It will keep trying until it acquires the lock. Well, we could also say that it waits quietly for the JVM to tell it that the lock is available. It's similar to wait/notify, but you, the programmer, don't have to do anything. The JVM will do it for you.

Alain Dickson Ranch Hand Joined: Dec 08, 2008 Posts: 53

posted 1/12/2009 1:48:34 AM

we could also say that it waits quietly for the JVM to tell it that the lock is available. It's similar to wait/notify,

well, can we say for sure that the Thread which is blocked, waits until the lock becomes available And that: 1. It does not wake up in-between to check if the lock is available 2. When the lock becomes available, Which notification JVM uses notify() OR notifyAll() Thanks, Alain

Mike Simmons Ranch Hand Joined: Mar 05, 2008 Posts: 2802

posted 1/12/2009 2:06:17 AM

A lain Dickson wrote:

well, can we say for sure that the Thread which is blocked, waits until the lock becomes available And that:

1. It does not wake up in-between to check if the lock is available

For sure? Probably not - I think the exact mechanism is implementationdependent. Note that I should not have said "wait" above, since in thread discussions that has a specific meaning which does not apply here. We can say that the thread, in general, does nothing until the lock is acquired. I suppose it's possible that in some implementations, threads might occasionally "wake up" and check their status. But whatever they do, you can assume it's something reasonably efficient. The threads do not, for example, spend all their time in loops, checking and rechecking their status. That would be a waste of resources, similar to a "busy wait".

www.coderanch.com/t/425685/threads/java/Blocked-Waiting-Thread

2/5

6/13/13

Blocked vs Waiting Thread (Threads forum at JavaRanch)

When you asked if a thread "keeps on trying until it gets the lock", my concern was that you might think the thread is wasting resources by repeatedly waking up and asking if the lock is available yet. In general, no, it doesn't. It's possible that some implementations may do this occasionally. But I wouldn't worry about it.

A lain wrote:

2. When the lock becomes available, Which notification JVM uses notify() OR notifyAll()

Neither of these. I said that the JVM does something like wait/notify - but it doesn't actually use wait(), notify(), or notifyAll(). However, I would guess that what it does is probably more like notify() than notifyAll(). There's no good reason to bother all the threads that are trying to acquire a lock. Better to pick just one, give it the lock, and tell it to run.

Chris Hurst Ranch Hand Joined: Oct 26, 2003 Posts: 376
I like...

posted 1/12/2009 7:20:13 AM

Adaptive locking was supposed to come in with Mustang and allow java to make an educated guess as to if spinning or suspension of the thread is more efficient in a blocked scenario.

"Eagles may soar but weasels don't get sucked into jet engines" SC JP 1.6, SC WC D 1.4, SC JD 1.5,SC BC D 5

Alain Dickson Ranch Hand Joined: Dec 08, 2008 Posts: 53

posted 1/12/2009 11:21:10 AM

Thanks Mike, Though from the discussion it makes sense both sychronized method calls and wait/notify are similar systems in terms of blocking thread and make it wait, but I would like to explicitly ask that: I have a situation where the design suggests to use wait/notify but I am thinking of redesigning it into synchronized method calls where (behaviour of wait/notify) is done by JVM not by program calling wait and notify explicity, which is prone to errors as compared to calls to synchronized methods. If the design allows, will synchronized methods give similar performance as wiat/notify where I know no thread will wake up until I call notify/notifyAll? Thanks, Alain

Mike Simmons Ranch Hand Joined: Mar 05, 2008 Posts: 2802

posted 1/13/2009 6:31:49 AM

That's an interesting idea. Yes, I would expect that both systems would probably give similar performance. If one is faster, I don't know which it would be - could be either. Probably the performance will be close enough either way that it doesn't matter, and your decision will be based on other considerations.

www.coderanch.com/t/425685/threads/java/Blocked-Waiting-Thread

3/5

6/13/13

Blocked vs Waiting Thread (Threads forum at JavaRanch)

Alain Dickson Ranch Hand Joined: Dec 08, 2008 Posts: 53

posted 1/14/2009 1:54:37 PM

Thanks for your valueable openion Mike. Regards, Alain

Steve Luke Bartender Joined: Jan 28, 2003 Posts: 3081

posted 1/14/2009 4:15:50 PM

A lain Dickson wrote:

Thanks Mike, Though from the discussion it makes sense both sychronized method calls and wait/notify are similar systems in terms of blocking thread and make it wait, but I

5
I like...

would like to explicitly ask that: I have a situation where the design suggests to use wait/notify but I am thinking of redesigning it into synchronized method calls where (behaviour of wait/notify) is done by JVM not by program calling wait and notify explicity, which is prone to errors as compared to calls to synchronized methods. If the design allows, will synchronized methods give similar performance as wiat/notify where I know no thread will wake up until I call notify/notifyAll? Thanks, Alain

A wait/notify system usually indicates that one thread can do some work concurrently with another, but has to specifically wait for the other thread to reach a certain point before it can proceed (say a consumer which can work on data, but must wait for the producer to make the data available before getting the next piece). Since you don't have control over thread scheduling the only thing you can do is call wait() to force the consumer to wait until the producer notify()s it of completion. Without wait/notify (or the Condition.await()/signal() from the concurrent api) you can't really get synchrony points points between different threads because you can't be sure which threads will get processor time and get the lock on the synchronized object. For example the consumer may get to a point where it has to block on a synchronized lock held by the producer. The producer releases the lock, but the thread maintains processor time, regains the lock, and keeps working. The poor consumer is still left in the blocking state, never having the chance to gain the synchronizing lock. So if you are looking to synchronize two threads in the fashion wait()/notify() allows, I think it would be rather difficult to execute using just synchronized methods because it would be hard to make sure any blocking thread ever gets some run time when it is needed. You might want to look at some of the classes in the java.util.concurrent package to make things easier, like a BlockingQueue
www.coderanch.com/t/425685/threads/java/Blocked-Waiting-Thread 4/5

6/13/13

Blocked vs Waiting Thread (Threads forum at JavaRanch)

to pass signals through, a Semaphore to provide permissions for the consumer to run, Lock/Conditions for a different synchronized lock/conditional wait and notification scheme, or the CyclicBarrier to allow multiple threads to come together to a single synchronized point. Many other options as well. See the java.util.concurrent API as well as the concurrency tutorial on Sun.

Steve

Alain Dickson Ranch Hand Joined: Dec 08, 2008 Posts: 53

posted 1/15/2009 9:33:41 AM

Thanks Steve, I have achieved my solution using the cocurrent package. It is very flexible and interesing. regards, Alain

I agree. Here's the link: http://aspose.com/file-tools

subject: Blocked vs Waiting Thread

Similar Threads K & B question 6 chapter 9(Threads). notify() effects on both threads that have/haven't called wait() From Velmurugan's Notes blocked state Java Thread Question
All times above are in your local time zone & format.T he current ranch time (not your local time) is Jun 13, 2013 03:31:08 .

Contact Us | Powered by JForum |

C opyright 1998-2013 Paul W he aton

www.coderanch.com/t/425685/threads/java/Blocked-Waiting-Thread

5/5