Threads: Why are Wait and notify declared in Object class?

I was thinking to improve my threading fundamentals, so I planned to make few notes for myself that will assist me in future (Obviously at the time of Interviews). Following questions and answers have been taken from stackoverflow.com. This post is a sticky notes post for me.

Source

This question has haunted me for quite a long time, so it would be interesting to understand the reasons to segregate respective methods from other thread related operations.

Java docs say the following

Wait method

public final void wait() throws InterruptedException

Causes current thread to wait until another thread invokes the notify() method or the notifyAll() method for this object. In other words, this method behaves exactly as if it simply performs the call wait(0).

The current thread must own this object's monitor. The thread releases ownership of this monitor and waits until another thread notifies threads waiting on this object's monitor to wake up either through a call to the notify method or the notifyAllmethod. The thread then waits until it can re-obtain ownership of the monitor and resumes execution.

As in the one argument version, interrupts and spurious wakeups are possible, and this method should always be used in a loop:

     synchronized (obj) {

         while (<condition does not hold>)

             obj.wait();

         ... // Perform action appropriate to condition

     }

This method should only be called by a thread that is the owner of this object's monitor. See the notify method for a description of the ways in which a thread can become the owner of a monitor.

Notify Method

public final void notify()

Wakes up a single thread that is waiting on this object's monitor. If any threads are waiting on this object, one of them is chosen to be awakened. The choice is arbitrary and occurs at the discretion of the implementation. A thread waits on an object's monitor by calling one of the wait methods.

The awakened thread will not be able to proceed until the current thread relinquishes the lock on this object. 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.

This method should only be called by a thread that is the owner of this object's monitor. A thread becomes the owner of the object's monitor in one of three ways:

• By executing a synchronized instance method of that object.
• By executing the body of a synchronized statement that synchronizes on the object.
• For objects of type Class, by executing a synchronized static method of that class.

Only one thread at a time can own an object's monitor.

Let’s try to understand it with one analogy.

One hotel has only one exclusive suite. It is quite popular. As only one couple can occupy one room, so other people enter their name in the wait list until person occupying the room does not check out of it.

So in this case, the room is a shared resource, and person occupying the room is a thread having a lock. Hotel management is JVM. Hotel management shares the key with first client and once he leaves the room, it picks up one client and notifies the chosen client.

Now let’s look at it with another prospective.

Let’s say hotel management does not want to handle this situation, so it provides client’s number, person who is occupying the room, to all the members. All these people call the client residing in hotel. So instead of enjoying the room, he will be busy in managing these calls, and he might probably sue hotel’s management.

There is one way around, hotel management provides client, having the key, the list of individuals who wanted to book the room next, but will any client accept to call other individuals? He will say that I do not care about calling anyone. You do your business and let me finish mine.

So what does about example signify?

It clearly indicates that none of the thread either cares about other threads or wants to be disturbed while performing its own operations. To avoid this scenario JVM tells every thread to wait on an object, instead talking to threads. This is why wait and notify are part of object instead thread.

Introducing new terms i.e. Monitors

The most simple and obvious reason is that any Object (not just a thread) can be the monitor for a thread. The wait and notify are called on the monitor. The running thread checks with the monitor. So the wait and notify methods are in Object and not Thread.

Example

public class ConnectionPool {
 private List<Connection> connections = createConnections();

 private List<Connection> createConnections() {
   List<Connection> conns = new ArrayList<Connection>(5);
   for (int i = 0; i < 5; i++) {
     ... add a Connection to conns
   }
   return conns;
 }
}

public Connection getConnection() throws InterruptedException {
 synchronized (connections) {
   while (connections.isEmpty()) {
     connections.wait();
   }
   return connections.remove(0);
 }
}

public void returnConnection(Connection conn) {
 synchronized (connections) {
   connections.add(conn);
   connections.notify();
 }

}

This is a typical example of consumer producer problem. In this case we have a connection pool which has 5 connections. Now different thread can request for connections, so connection pool must check whether it has capacity to provide one connection or not. If it has one connection, it will provide it else other wise it will ask thread to wait for connections to release. So here thread will wait on connection. In other words it can be said thread is waiting for connections. Same applies in the case of notify. Once any thread releases the connection, that will added to pool and one of the threads will be notified to grab the newly released connection.