Siddharth Bhargava wrote:
Yes I did went through the Java docs. What exactly does this line "The wait() method releases the lock prior to waiting and reacquires the lock prior to returning from the wait() method. The wait() method is actually tightly integrated with the synchronization lock, using a feature not available directly from the synchronization mechanism. In other words, it is not possible for us to implement the wait() method purely in Java: it is a native method.." mean ?
In my opinion, the quote doesn't really say anything that useful. Who cares if the wait() method can't be done purely in Java? Isn't that just an implementation detail?
Anyway, if you ever use any other threading environment, such as Solaris threads, POSIX threads, or even Windows threads, you have use this feature / functionality before. It goes by the name of "condition variable". And it is tightly integrated with an mutually exclusive lock (mutex), which in Java is implemented via synchronization. Java also implements the mutex and condition variable differently but that's for a different discussion.
What a condition variable does is atomically send a notification (signal) from one
thread to another. To be atomic, it must use the mutex (must own the lock). And for the thread that must wait for the notification, it must free the lock -- or else, it won't be possible for the send thread to own the lock to send the notification.
And unfortunately, this can't be done without tightly integrating those two features. Not integrating it, will make it possible for notifications to be lost... and unfortunately, this may be a bit hard to envision.
Anyway, perhaps
you should do some research on "condition variables" in general. Since, this feature is available with practically all threading environments, you have other documentation to rely on here (don't need to be specific to Java).
Henry