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.
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.
- Consumer thread invokes, and makes a call to get method. It checks that nothing is available, and consumer thread enters in the while block.
- JVM starts producer thread here.
- Producer thread puts the information and invoke notify.
- As consumer has not reached to the wait state, so it does not care about it.
- Now consumer has started waiting.
- 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.
- 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.
- JVM starts producer thread here.
- Producer thread puts the information and invoke notify.
- As consumer is in wait state, so it will awake at notify call.
- Consumer will consume the information and notify the producer to generate more information.
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.
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.
No comments:
Post a Comment