• 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

if notify() cannot take a target argument, when is it useful?

 
Ranch Hand
Posts: 140
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

It appears notifyAll() is most commonly used, as notify cannot target one specific thread.
So when is notify() useful? Only when you have created a single thread that is started?
 
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Nigel,

notify() belongs to java.lang.Object (and not to java.lang.Thread) - besides, every Object has a built-in lock which comes into play when a synchronized method (or code block) is entered by a Thread. Now, such thread owns the lock on this object, provided that the synchronized method is not static (otherwise, the thread would have a class lock rather than an object lock).

The notify() is related to a so-called monitor, notifying ONE waiting thread that the lock (monitor object) will be released "very soon" (please take into account that the lock is definitely released exactly when the synchronized method (or code block) has finished - after this, the waiting thread (which has invoked "wait()" before) can continue its work - generally elaborating the data coming from the monitor.

It's crucial to notice that both synchronized blocks (where wait() and notify() are taking place) are synchronized on the same object, for example
- synchronized (this) { .... this.notify(); } and
- synchronized (obj) { ... obj.wait(); ...}
(where "this" and "obj" are both references to the same instance of a class - otherwise, you would get an IllegalMonitorException!)

As soon as wait() is invoked, the Object (for example "obj") is provided with a list of all waiting threads (waiting for obj) - so the notify() method can only notify such threads which are at the list. Nevertheless, if there is more than one thread waiting for a notification, there's no guarantee WHICH thread will get the notification. If you want to notify all waiting threads (for obj), use notifyAll() instead of notify().

If it's sounds too complicated, please read SCJP 6 (K&B), page 746-752, "Thread Interaction".

Hope this helps!

P.S.: I've noticed too late that I've misinterpreted your question because of your headline. As you can see, my explanation goes into the direction "notify() without argument or target thread" ... indeed, use notifyAll() when it deals with more than one waiting thread
 
Nigel Shrin
Ranch Hand
Posts: 140
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ulrich,

That's brilliant thanks. I'm reading some more from K&B at the moment. So a programmer would nearly always use notifyAll() but notify() is more used by the JVM at a fine grain level?
If ThreadA enters a wait state within a synchronized block, it is said that to call notify (or notifyAll) the caller has to own the lock on the object. So ThreadA must relinquish the lock temporarily
when waiting?

Thanks
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Nigel Shrin wrote:That's brilliant thanks. I'm reading some more from K&B at the moment. So a programmer would nearly always use notifyAll() but notify() is more used by the JVM at a fine grain level?



No. There are a few reasons to use the notifyAll() method. The most common reason is that you actually need to wake up more than one thread. Another reason is that it is not possible to determine how many threads need to wake up, at the time of notification.

In the case of "using notifyAll() instead of notify() because you can't target the right thread", it is generally caused by a bad application design. Threads should be waiting for a state, and all threads waiting for that state should be interchangeable. If only a particular thread needs to handle it, then they should not be waiting on the same object.

Now, having said that, there is a flaw with the original wait/notify design. With all other threading systems -- Windows, POSIX, Solaris, etc. -- it is possible to have more than one condition variable sharing the same mutex lock. With Java, the object used for synchronization is also the notification object, and hence, not possible for two notification objects to be the same synchronization object. This was fixed with Java 5. With Java 5, it is now possible to have more than one condition variables share the same mutex (see the ReentrantLock class and the Condition interface).

Henry
 
Nigel Shrin
Ranch Hand
Posts: 140
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Henry, thank you for taking the time to explain that. I hadn't realised the point "Threads should be waiting for a state, and all threads waiting for that state should be interchangeable".
Cheers
 
Ulrich Vormbrock
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks a lot, Henry!

Your explanation is very insightfull, indeed!
You mentioned the design issue which comes into play relating multiple threads waiting for notification.
I see that it's bad design if more than one thread keeps waiting for a single object.

Maybe, I'll read your book concerning threads - at least when I'll have passed the SCJP 6 exam ;-)
 
Do the next thing next. That’s a pretty good rule. Read the tiny ad, that’s a pretty good rule, too.
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic