• 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

notify

 
Ranch Hand
Posts: 637
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
notify: Wakes up a single thread that is waiting on this object's monitor. If any threads are waiting on this object, one of them is chosen to be awakened. The choice is arbitrary and occurs at the discretion of the implementation. A thread waits on an object's monitor by calling one of the wait methods.

Since it invokes an arbitary method, I don;t understand what is the purpose of such an un-reliable method. {Unreliable: Chooses arbitary thread}.
Someone ps explain.
 
Sheriff
Posts: 9707
43
Android Google Web Toolkit Hibernate IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
it is a matter of circumstances. Suppose you have a design where there is a pool of objects. Whenever any thread requires an object, it comes and retrieves an object from the pool. If an object is not found, then the thread starts to wait on that object. The class that manages the pool calls notify whenever an object is back in the pool. Since it notifies threads when 1 object is received back, so it will have to notify only one of the waiting threads. There is no use of notifying all the waiting threads as only one of them will be able to use the object from the pool. This kind of situations require you to use notify instead of notifyAll...
 
Ranch Hand
Posts: 1710
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Agreeing to what Ankit said, here the question is why choosing arbitrary
thread
from the pool of waiting thread?
The strategy depends much on how thread choosing implementation has been
written. It may apply best choosing mechanism as giving opportunity to the
least time requiring thread (a thread that holds the object for least time)
or priority based choosing, or may be following first come first served basis.

The implementation could be anything I suppose, and ultimately at a time
only one thread has to be given the lock of the object. I suppose by setting
the thread priority we can control this thread picking mechanism to some
extent. But its also not very sure to be followed.

Further comments on this is solicited.
 
Deepak Jain
Ranch Hand
Posts: 637
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Makes sense.

If only one thread is required to be awakened then why awake all of them.
 
Ranch Hand
Posts: 210
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Since it invokes an arbitary method, I don;t understand what is the purpose of such an un-reliable method. {Unreliable: Chooses arbitary thread}.


It may be that that synchronisation is `fair' and guarantees eventual servicing of the Thread but I've not seen that promise made in the (informal) Java specification
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If the specification had said "It awakens the thread which has been waiting longest" or "It awakens the thread which has the highest priority" or anything else specific, then people would be asking why that particular choice had been made. And how to get the JVM to make some other choice. And why we couldn't have a system property that controlled which choice was made. And on and on. No, that keeps things simple.

Really there's no particular choice that is right in all situations. So why make a choice? Choosing a random thread is actually a pretty good procedure in a lot of cases, and for people who need some particular sequencing or prioritization, well, they can program that themselves.
 
Aum Tao
Ranch Hand
Posts: 210
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Paul Clapham:
If the specification had said "It awakens the thread which has been waiting longest" or "It awakens the thread which has the highest priority" or anything else specific, then people would be asking why that particular choice had been made. And how to get the JVM to make some other choice. And why we couldn't have a system property that controlled which choice was made. And on and on. No, that keeps things simple.

Really there's no particular choice that is right in all situations. So why make a choice? Choosing a random thread is actually a pretty good procedure in a lot of cases, and for people who need some particular sequencing or prioritization, well, they can program that themselves.


Agreed, Paul. Leaving the choice of implementation to the programmer seems to provide more flexibility.
 
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

Originally posted by Prateek Parekh:

Agreed, Paul. Leaving the choice of implementation to the programmer seems to provide more flexibility.




The other reason it is so "undefined" is because notification is done by the underlying operating system -- ie. native condition variable support. By saying it is arbitrary, it can be implemented by all the native OS threading systems easily.

Henry
[ December 08, 2008: Message edited by: Henry Wong ]
 
Ranch Hand
Posts: 265
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
what is arbitrary thread?
please explain me...

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

Originally posted by Preetha Arun:
what is arbitrary thread?
please explain me...

Thanks
Preetha



-> Random thread from the pool of waiting threads to choose from.
-> A thread that is chosen from the pool of waiting threads for assigning the
lock of individual object for time being to it (so called arbitrary thread)
 
Aum Tao
Ranch Hand
Posts: 210
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here, arbitrary means the same thing it does in common English i.e. not governed by specific rules.
reply
    Bookmark Topic Watch Topic
  • New Topic