This week's book giveaway is in the Artificial Intelligence and Machine Learning forum.
We're giving away four copies of Zero to AI - A non-technical, hype-free guide to prospering in the AI era and have Nicolò Valigi and Gianluca Mauro on-line!
See this thread for details.
Win a copy of Zero to AI - A non-technical, hype-free guide to prospering in the AI era this week in the Artificial Intelligence and Machine Learning forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Liutauras Vilda
  • Paul Clapham
  • Bear Bibeault
  • Jeanne Boyarsky
  • Ron McLeod
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Jj Roberts
  • Stephan van Hulst
  • Carey Brown
  • salvin francis
  • Scott Selikoff
  • fred rosenberger

notify() effects on both threads that have/haven't called wait()

Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Ranchers,

I'm experimenting on threads for the OCPJP6 exam. I've read the description of the notify() method of class java.lang.Object, and there's a point that it's not much clear to me:

The awakened thread will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened thread enjoys no reliable privilege or disadvantage in being the next thread to lock this object.

1)Does this mean the following ?
If two threads t1 and t2 are running and t1 calls wait() on a lock "l", and t2 is already waiting on l (it's stopped just before a synchronized(l){} block), then when a thread t3 calls l.notify() it will restore t1 from the blocked state into running. Here, it may cause either t1 or t2 to continue execution without favoring t1 (i.e. the awakened thread) in any way.

I wrote a small program to test this behavior, but it is inconsistent with what stated by the description, in that the awakened thread seems always choosen instead of the other one simply waiting on a synchronized block.
2) So, where is my mistake in this code ?

Here, three threads are instantiated and executed on the fly and sequentially by the main thread. Each have a block synchronized on the same lock (namely, the instance of the outer class that created the threads). The aim of this is to call notify() on a lock that is conteded by a just-awakened thread and a thread waiting on a synchronized block.
The first thread gets the lock, then calls wait() and releases it. Now it's blocked and waiting that some other thread calls notify(); in the meantime, the second thread gets the lock and goes to sleep for 1 second; by the time it calls notify() the third thread will be already waiting on a syncronized block, so the call to notify() will happen in the scenario described in 1).
Posts: 4179
IntelliJ IDE Python Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is nearly impossible to prove or disprove this sort of thing. The comment you quote says there is no guarantee one way or another as to which thread might get the lock next. Implementation details of a particular OS, JVM version, or just plain luck may indicate otherwise - and in your testing environment which is much simpler than any real world scenario, you are getting what looks like consistent behavior. But that behavior can and will change when the number of threads change, the version of the JVM changes, etc... The quote tells you that you can not rely on any type of expected behavior. The conclusion is, if you need to ensure one thread gets access to the lock before another one then you must code that behavior yourself to ensure it behaves reliably.
Consider Paul's rocket mass heater.
    Bookmark Topic Watch Topic
  • New Topic