• 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

JTest and threads

 
Trailboss
Posts: 23773
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A question on JTest asks
<pre>
Which methods may stop a thread from executing?
A. sleep()
B. stop()
C. yield()
D. wait()
E. notify()
F. notifyAll()
G. synchronized()

</pre>
The answer given by JTest is A, B, C and D.
What about E and F? I thought that notify() would stop the thread and give control to somthing that is waiting?
 
Ranch Hand
Posts: 508
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No. I believe it just takes a thread in the Monitor's (the Object with the synchronized methods/statements) pool and puts it into the Ready state. It does not force the current thread to yield.
 
paul wheaton
Trailboss
Posts: 23773
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You are correct that it does not release the CPU - this much I have figured out since posting that question.
But, does it move it to the "ready" state, or the "waiting for lock" state? (is there a "waiting for lock" state?)
 
Ranch Hand
Posts: 165
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Umm, those terms are confusing.
Monitor can be locked or unlocked. A thread can be waiting on monitor, having the monitor locked (resource is busy) or waiting for the monitor to unlock (waiting for a resource).
So, notify() just tells the monitor the wait() should be finished, but doesn't change the monitor's ownership(locking). So, if you have one thread waiting on monitor and another doing notify() on the same monitor, the execution of the first thread will continue only after the second thread will release the monitor (exit 'synchronized' block).

------------------
With best of best regards, Pawel S. Veselov ( aka Black Angel )

 
Ranch Hand
Posts: 216
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
According to RH
Notify method selects one of the thread in the monitors waiting pool and moves it to Seeking lock state.
Eventually when it gets the lock it is executed
reply
    Bookmark Topic Watch Topic
  • New Topic