Johnny_hunter wrote:Nothing changes for the thread owning the monitor: It will continue to hold the monitor (as it should!). Notify() (or better yet: notifyAll()) will inform a waiting thread (or threads for notifyAll()), that the monitor will become available again and that they should queue up to re-obtain the monitor. Once a thread obtains the monitor it will exit the wait() method and continue. Usually it starts with re-checking its wait-condition and either wait again or continue processing).
I always thought that notify() wakes up one of the threads waiting on the object's monitor, AND the thread owning the monitor (the same one calling notify) release the object's lock as well.
However, I took another look at java doc, it only states the wake-up-waiting-thread part. That brings me to think that my earlier assumption could be wrong and therefore two questions cross my mind:
1. When notify is called, what's the state does the owning thread change to?
2. If I want to release the lock from the owning thread, is it a common practice that the owning thread calls wait() after calling notify() inside the sync block? I did see code like that, but not very often.The thread holding the monitor either continues process, and then either leaves the synchronisation block, or calsl wait(). It all depends on what you need to do, and what further processing is needed.