aspose file tools*
The moose likes Threads and Synchronization and the fly likes Blocked vs Waiting Thread Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Blocked vs Waiting Thread" Watch "Blocked vs Waiting Thread" New topic
Author

Blocked vs Waiting Thread

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

Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
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
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: 3018
    
  10
Alain 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 implementation-dependent.

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".

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.

Alain 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: 417
    
    2

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" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
Alain Dickson
Ranch Hand

Joined: Dec 08, 2008
Posts: 53
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: 3018
    
  10
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.
Alain Dickson
Ranch Hand

Joined: Dec 08, 2008
Posts: 53
Thanks for your valueable openion Mike.

Regards,
Alain
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

Alain 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 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 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
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