This week's book giveaways are in the Refactoring and Agile forums.
We're giving away four copies each of Re-engineering Legacy Software and Docker in Action and have the authors on-line!
See this thread and this one for details.
Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Confirming notify()

 
Vikrama Sanjeeva
Ranch Hand
Posts: 760
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is not must that the Thread which called the notify() will leave the running state.Since if there will be no Thread in waiting pool,then to whome it will notify?, and therefore will continue to run.
Is this concept is correct?
Bye.
Viki.
------------------
Count the flowers of ur garden,NOT the leafs which falls away!
 
Rashmi Tambe
Ranch Hand
Posts: 418
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Vikrama Sanjeeva:
It is not [b]must that the Thread which called the notify() will leave the running state.Since if there will be no Thread in waiting pool,then to whome it will notify?, and therefore will continue to run.
Is this concept is correct?
Bye.
Viki.
[/B]

That's right vikram...the thread calling notify does not necessarily leave the running state irrespective of how many or which threads are notified. It totally depends on the scheduler. Therefore can't be predicted! Even if there r threads in waiting pool there's no guarantee that one of the notoified threads would run immediately.
HTH
Rashmi
 
Jose Botella
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is not the call to notify, the one that makes the threads waiting to compite to adquire the lock, but the call to wait. Also if the run methods of the running thread ends.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic