• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Blocked vs Waiting Thread

 
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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

 
Master Rancher
Posts: 4796
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Master Rancher
Posts: 4796
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Ranch Hand
Posts: 443
3
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Alain Dickson
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Master Rancher
Posts: 4796
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your valueable openion Mike.

Regards,
Alain
 
Bartender
Posts: 4179
22
IntelliJ IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Alain Dickson
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Steve,
I have achieved my solution using the cocurrent package. It is very flexible and interesing.

regards,
Alain
 
reply
    Bookmark Topic Watch Topic
  • New Topic