Why wait, notify and notify? All methods in object class are not like Cloneable
I was recently asked in an interview why wait
, notify
and notifyAll
. I explained to them.
After that, they asked me to assume that the application is always single threaded. Is this really required? My answer was no.
Then they asked why design similar to wait
, notify
and notifyAll
is a class method Object
. Why does Java not have an interface, and these methods are in that interface, and which ever a class wants to implement, it can use it. So, I was stuck and couldn't ponder this design. Can anyone internalize this light?
source to share
The JVM uses OS level threads. This means that each specific JVM for each specific OS handles threads differently. And these methods are not only implemented in the class Object
, they are marked as native
, which means that they are implemented in the JVM system layer.
And if these methods were in some kind of interface, that would mean that someone could override them.
source to share
Pending and notice and notice. These are not just ordinary methods or a synchronization utility; moreover, they are a communication mechanism between two threads in Java. The Object class is the right place to make them available to every object if that mechanism is not available through any java keyword like synchronized. Remember, synchronized and awaited notifications are two different areas and don't be confused that they are the same or related. Synchronized to enforce mutual exclusion and to enforce Java class thread safety such as race conditions, while waits and notifications are the communication mechanism between two threads.
source to share
Then they asked why design similar to
wait
,notify
andnotifyAll
is a class methodObject
. Why does Java not have an interface, and these methods are in that interface, and which ever a class wants to implement, it can use it.
All of these methods are implemented in their own code, and they are tightly integrated with the block synchronized
that wraps them. They are part of the Java language definition and have specific behaviors that programmers rely on. It would be inappropriate for them to use interface methods that any object could implement.
When one object calls obj.wait();
on another object, it doesn't need to worry about implementation wait
. He must make sure that he has a mutex lock on this object so that he can make critical updates to him or another store, and if the method wait
was implemented by the object itself, then this object could violate language requirements and for example allow concurrent use multiple threads in a protected block. A thread can synchronize
and does call wait
/ notify
/ notifyAll
on another object or not, without worrying about whether that object has correctly implemented these methods. By making them final
methods on Object
, the behavior will work the same regardless of the object type or local implementation.
Also, as I said, wait
/ notify
/ notifyAll
is closely related to the surrounding block synchronized
. When a thread is blocked in wait()
, the surrounding lock is closed synchronized
so that other threads can access the protected block. This coordination would not have been possible if it wait()
was just a simple method call without other strange language features.
This reminds me of my other answer here: Concept behind wait (), notify () methods in object class
source to share
From the beginning, there was a design goal that Java programs would be multithreaded. Remember, Java's plan to make embedded programming less intimidating, the whole web application on the server business (which led to the commercialization of Sun's core business) was an accident.
Since the goal was to create embedded apps that could talk to other devices, it must be multithreaded to be network friendly and event driven. But writing efficient multithreaded servers was not on the list for java.
Java hasn't had ReentrantLock or non-blocking I / O in a long time. Initially, the main data structures available were Vector, Hashtable and StringBuffer (all of which were synchronized across all public methods). From this choice, it seems that the goal was good enough, not as effective as possible. Later, it was clear that Java should be more efficient for server-side applications and the 1.2 introduced Vector and Hashtable equivalents that were out of sync. It seemed like an afterthought, a course correction made when it was obvious that Java had a new role that it was not intended to be previously.
If Java remained in the niche, it was created so that perhaps inline locks could be adequate. It seems that the original plan was for built-in locks only, so the lock could also be connected to the facility.
source to share