Help coderanch get a
new server
by contributing to the fundraiser
  • 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
  • Ron McLeod
  • Paul Clapham
  • Devaka Cooray
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Tim Moores
  • Carey Brown
  • Mikalai Zaikin
Bartenders:
  • Lou Hamers
  • Piet Souris
  • Frits Walraven

Thread-doubt on wait

 
Ranch Hand
Posts: 58
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


These classes are defined in the same file. What is the output? (1 correct answer)

1.It prints 0.
2.It prints 999999.
3.The output is not guaranteed to be any of the above.



Ref:Nikos' Java blog-SCJP 6 Mock exam for Threads(Q 66).
Correct Answer:2

Could you please explain the output?I expected the main thread to wait indefinitely in absence of notify()/notifyAll().
 
Saloon Keeper
Posts: 15702
367
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Personally I believe the answer should be option 3. The call to wait() may return at any moment, because of spurious wakeups. So the program may print some arbitrary value between 0 and 999999, or it may not terminate at all.
 
Sebanti Sanyal
Ranch Hand
Posts: 58
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for your reply. Is there any correlation between the end of run() method and release of locks or notification?
 
Stephan van Hulst
Saloon Keeper
Posts: 15702
367
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There is no correlation between the finishing of the run() method and the release of locks or notification. However, there may be a correlation between the finishing of a run() method and spurious wakeups.

I tested the program myself, and it indeed prints 999999, but I don't think this can be guaranteed. If I remove the thread.start() statement, the program runs indefinitely, so I believe the termination of a thread may cause other wait() statements to return spuriously. Again, this is an artifact of the implementation, and the results may differ on different operating systems or different virtual machines.
 
Sebanti Sanyal
Ranch Hand
Posts: 58
Eclipse IDE C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you very much Stephan for the clear explanation.
 
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Stephan,

The call to wait() may return at any moment, because of spurious wakeups.



I'm not sure what is meant by this. In given code, nobody is explicitly calling notify/notifyAll method on thread, so it is very very unlikely (rather I would say impossible) to get out of wait method before thread execution is finished. Once run method is executed, 'wait' will be over.

If I remove the thread.start() statement, the program runs indefinitely



This happened because, thread was not running, nobody's gonna ever call notify/notifyAll on that thread, and hence 'wait' will never end.

Hence, in my opinion, output should (and would) be 999999.
reply
    Bookmark Topic Watch Topic
  • New Topic