Why are wait () and notify () declared in the Java Object class?

Question

Why are the wait() and notify() methods declared in the Object class and not the Thread class?

Answer 1

Because you expect this object (or, in particular, its monitor) to use this functionality.

I think you may be mistaken in how these methods work. They are not just at the level of detail, i.e. This is not a case of just calling wait() and waking up the next call to notify() . Most likely, you always call wait() on a particular object and you will only wake up with notify calls on that object .

This is good, because otherwise the concurrency primitives just won't scale; this would be equivalent to having global namespaces, since any calls to notify() anywhere in your program could ruin any parallel code, as they would activate thread blocking when wait() called. Hence the reason why you call them a specific object; it provides a context for a wait wait pair to work, so when you call myBlockingObject.notify() on a private object, you can be sure that you are only waking up threads calling wait methods in its class. Some Spring thread that can wait on another object will not be woken up by this call and vice versa.

Edit: Or refer to it from a different perspective - I expect from your question that you thought you would get a handle to the waiting thread and call notify() on that thread to wake it up. The reason this is not the case is because you have to do the housework yourself. A thread that will wait will have to post a link to itself somewhere that other threads might see it; it must be properly synchronized to ensure consistency and visibility. And when you want to spill a thread, you will need to cope with this link, wake it up and delete it where you read it. It involves a lot more manual scaffolding and is much more likely to deal with it (especially in a parallel environment) compared to just calling myObj.wait() in a sleep thread and then myObj.notify() in a waker thread.

Answer 2

The simplest and most obvious reason is that any object (not just a stream) can be a monitor for the stream. Waiting and notification are called on the monitor. The current thread is checked by the monitor. Therefore, the wait and notify methods are in Object and not Thread

Answer 3

Because only one thread at a time can own an object’s monitor, and this monitor is what the threads expect or notify. If you are reading javadoc for Object.notify() and Object.wait() , this is described in detail.

Answer 4

The synchronization mechanism includes a concept - an object monitor. When wait () is called, the monitor is queried, and further execution is paused until a monitor is received or an InterruptedException occurs. When notification () is called, the monitor is released.

Take the script if wait () and notify () were placed in the Thread class instead of the Object class. At some point in the code, currentThread.wait() is called and then accesses the anObject .

 //......... currentThread.wait(); anObject.setValue(1); //......... 

When currentThread.wait () is called, the currentThread monitor is monitored, and no further execution is performed until a monitor is detected or an exception is thrown. Now, in the standby state, if the foo() method of another anotherObject in currentThread is called from another thread, it gets stuck even if the called foo() method does not have access to anObject . If the first wait () method was called on anObject , instead of the thread itself, other method calls (without accessing anObject ) on objects in the same thread were not stuck.

Thus, calls to the wait () and notify () methods for the Object class (or its subclasses) provide higher concurrency and why these methods are in the Object class and not in the Thread class.

Answer 5

A few other answers use the word "monitor", but no one explains what this means.

The name “monitor” was introduced back in the 1970s, and it referred to an object that had its own internal lock and associated waiting / notification mechanism. https://en.wikipedia.org/wiki/Monitor_%28synchronization%29

Twenty years later, there was a brief moment in time when desktop, multiprocessor computers were new, and it was fashionable to think that the right way to develop software for them would be to create object-oriented programs in which each Object had a monitor.

It turns out that this was not such a useful idea, but this short moment occurs exactly when the Java programming language was invented.

Answer 6

Read here for an explanation of the expectation and notice.

It is better to avoid them, however, in your applications and use the new java.util.concurrent package.

Answer 7

I will put it in a simple way:

To call wait () or notify (), you need to own an object monitor - this means that wait () or notify () must be present in the synchronized block

 synchronized(monitorObj){ monitorObj.wait() or even notify } 

That is why these methods are present in the object class.

Answer 8

This is due to the fact that these methods are intended for communication between threads, and interthreadcommunication occurs using locks, but locks are associated with objects. If it is in a feature class.

Answer 9

The Wait and Notify methods use the relationship between two threads in Java. Thus, the Object class is the right place to make them available for every object in Java.

Another reason is that locks are available for each object. Threads require a lock, and they wait for a lock, they don’t know which threads contain the lock, and they just know that the lock is held by some thread, and they should wait for the lock instead of knowing which thread is inside the synchronized block, and ask them to release the lock