Threads: Why must wait() always be in synchronized block?

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 is more specific to design aspect of java. Why should object.wait() method be called from a synchronized block? Why is this necessary to acquire monitor of the object? Why cannot application ask a Running thread to wait for sometimes? (Very similar to sleep)

As per the accepted answer, wait and notify are used for inter thread communication. When a thread is waiting for nothing, then what specific condition should wake this thread? On what grounds JVM sends a notification to the thread?

In another answer, an explanation is provided with an example.

package com.thread.problem;

public class Information {

                private String message;

                private boolean isAvailToWrite = false;

                public boolean isAvailable(){

                                return isAvailToWrite;

                }

                public boolean isUnavailable(){

                                return !isAvailToWrite;

                }

                public void put(String msg) throws InterruptedException{

                               while(isUnavailable()){

                                                                System.out.println("Producer will wait now.");

                                                                wait();

                                                }

                                                message = msg;

                                                isAvailToWrite = true;

                                                notify();

                }

                public String get() throws InterruptedException{

                                while(isAvailable()){

                                                                System.out.println("Consumer will wait now.");

                                                                wait();

                                                }

                                                isAvailToWrite = false;

                                                notify();

                                                return message;

                }

}

There are 2 threads i.e. producer and consumer. Producer is calling put method to generate the Information, whereas consumer is digesting this specific information.

Now let’s assume things happen in following sequence.

1. Consumer thread invokes, and makes a call to get method. It checks that nothing is available, and consumer thread enters in the while block.
2.  JVM starts producer thread here.
3. Producer thread puts the information and invoke notify.
4. As consumer has not reached to the wait state, so it does not care about it.
5. Now consumer has started waiting.
6. Producer is never invoked after that.

So in this case main will keep running and no output will be generated.

Adding synchronized blocks to the above solution. No thread will be in intermittent state, and producer and consumer will work as expected.

package com.thread.problem;

public class Information {

                private String message;

                private boolean isAvailToWrite = false;

                public boolean isAvailable(){

                                return isAvailToWrite;

                }

                public boolean isUnavailable(){

                                return !isAvailToWrite;

                }

                public void put(String msg) throws InterruptedException{

                                synchronized (this) {

                                                while(isUnavailable()){

                                                                System.out.println("Producer will wait now.");

                                                                wait();

                                                }

                                                message = msg;

                                                isAvailToWrite = true;

                                                notify();

                                }

                }

                public String get() throws InterruptedException{

                                synchronized (this) {

                                                while(isAvailable()){

                                                                System.out.println("Consumer will wait now.");

                                                                wait();

                                                }

                                                isAvailToWrite = false;

                                                notify();

                                                return message;

                                }

                }

}

Now let’s follow the sequence specified above.

1. Consumer thread invokes, and makes a call to get method. It checks that nothing is available, and consumer thread enters in the while block. It can only exit until it completes its operations. So it will reach to wait state.
2. JVM starts producer thread here.
3. Producer thread puts the information and invoke notify.
4. As consumer is in wait state, so it will awake at notify call.
5. Consumer will consume the information and notify the producer to generate more information.

Here is one good explanation for the need of wait in a synchronized block.

 wait() isn't strictly guaranteed to do anything at all. Something called "spurious wakeups" might occur. That is, a call to wait() can
return at any time without any good reason. So a good rule of thumb for using wait() is that you should consider it to be nothing but an optimization. If a program issn't correct already (and assuming that thread starvation is not occurring), calling wait() can NOT make a program correct. However, it certainly can make a program incorrect!

So we need to start out thinking of how we'd write the code without wait at all. So how do you wait for something is wait() doesn't do anything? Easy... you do a busy-wait:

while (!thingImWaitingFor()) /* DO NOTHING */;

This uses 100% of the CPU power available, of course, and performance horribly. The optimization is this:
while (!thingImWaitingFor()) wait();

That explains the need for a "condition", which in this case is !thingImWaitingFor(). Next, you need a guarantee that the
waiter and the notifier agree about the state of the condition. The waiter checks the state of the predicate at some point slightly BEFORE it goes to sleep, but it depends for correctness on the condition being true WHEN it goes to sleep. There's a period of vulnerability between those two events, which can break the program. (Vulnerability has been explained above with the producer and consumer example)

You need that period of vulnerability to be protected by a synchronized block. If the waiter didn't synchronize, then any old bit of code might change the predicate just before it goes to sleep, and then we're certainly in trouble. If the notifier didn't synchronize, then it could change the predicate even though the waiter is holding the lock, and we are screwed.

However, the waiter can't hold a synchronized lock while it's waiting. At first glance, this problem seems impossible. Now, there's actually a bit of magic involved here. The wait() method ATOMICALLY releases the lock and goes to sleep. It's a sort of deus ex machina solution (deus == Java Virtual Machine) to the otherwise impossible problem. 

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.