Thread question

[Ramesh Tiwari]

Why do we need to call wait() and notify in a synchronized context,in other words, why do we need to get the lock of the object to call wait().
Why can't we directly call wait() on an object without locking the object.
Please explain.
Thanks

[Marlene Miller]

I hope you don�t mind a long answer. But the question you have asked is very important and should be treated accordingly.

Why do we need to call wait() and notify in a synchronized context

A thread might not want to perform some action on an object unless it is guaranteed that object is in the correct state.
There are two approaches to handle this. (1) Optimistic try-and-see: Methods can always be tried when invoked, but do not always succeed, and thus may have to deal with failure. (2) Conservative check and act: Methods refuse to proceed unless preconditions hold. When preconditions do hold, the actions always succeed.
The wait-and-notify mechanism uses the conservative approach. The thread blocks until a precondition becomes true.
The standard coding idiom (which we rarely if ever see in these exam prep books and mock exams) is a simple while loop invoking wait.

  synchronized void m() throws InterruptedException {
    while (condition) wait();
    // do something
  }

Everything is executed in synchronized code. If it were not, the state of the object would not be stable. If the method were not declared synchronized, then after the while statement, there would be no guarantee that the condition remained true because another thread may have changed the condition that is being tested.
On the other side, the notification methods are invoked by synchronized code that changes one or more conditions on which some other thread may be waiting.
[ July 13, 2003: Message edited by: Marlene Miller ]

[Marlene Miller]

I am still working on understanding the concepts underlying the wait-notify mechanism.
A better answer to your question has something to do with monitors. Entities possessing both locks and wait sets are generally called monitors. In Java, any Object can serve as a monitor.
A monitor provides a set of operations that are the only means by which an object can be manipulated. A process can access the variables in a monitor only by calling one of the monitor�s procedures.
Monitor procedures by definition execute with mutual exclusion. In particular, it is up the implementation of the language, library, or operating system to provide mutual exclusion. It is not up to the programmer who uses monitors. In practice, languages and libraries implement mutual exclusion by using locks or semaphores.
Gregory Andrews, Foundations of Multithreaded, Parallel, and Distributed Programming
See Chapter 5: Monitors and Case Study: Java
[ July 13, 2003: Message edited by: Marlene Miller ]

[Marlene Miller]

Three more thoughts on this question:
(1) I gave two relatively elaborate answers above, one about guarded methods (according to Doug Lea) and the other about monitors (according to Gregory Andrews).
But Paul Hyde has a nice simple way of explaining it in his book Java Thread Programming. He says the checking and modification occur inside the synchronized blocks to be sure that no race conditions develop. Synchronization on the object controls concurrent access to the object.
(2) Paul Hyde also points out that the wait/notify mechanism does not *require* that a condition be checked by one thread and set by another. However, it is generally a good idea to use this mechanism in conjunction with at least one variable. Doing so helps in avoiding missed notifications and in detecting early notifications. He gives two very nicely written examples.
(3) In truth, I could not explain above why notify must be synchronized. After all, when the second thread notifies the waiting thread(s) and then exits the synchronized block, another thread could change the condition again before the notified thread(s) is scheduled to run again.
Now I know why. The waiting thread of course has to be synchronized, so that the state of the object does not change between the time the condition is checked and the code after the condition executes. Therefore, all methods reading or changing the condition must be synchronized. Otherwise the first thread might test the condition, then the second thread in an unsynchronized method changes the condition and calls notify that is ignored, then the first thread calls wait and misses the notification.
(As you can see, this question really interests me. For a long while I use to wonder the same thing myself. Sorry for the long posts. The better I understand it, the more concise my answers will become.)

[Ramesh Tiwari]

Thank you very much Marlene.

[Marlene Miller]

Ramesh, I hope you were able to condense what I said into something meaningful and useful to you. I hope you did not suffer from buffer overflow.
It's the first time I have tried to articulate these interesting ideas on wait-and-notify. I got a bit carried away, didn't I?
I am sure I will hear about it from some of the other Ranch hands.

[Anupam Sinha]

Hi Marlene
I agree with you this question is really interesting. Sometime back I thought about this thing and then after getting no concrete answer just left the question.

(3) In truth, I could not explain above why notify must be synchronized. After all, when the second thread notifies the waiting thread(s) and then exits the synchronized block, another thread could change the condition again before the notified thread(s) is scheduled to run again.
Now I know why. The waiting thread of course has to be synchronized, so that the state of the object does not change between the time the condition is checked and the code after the condition executes. Therefore, all methods reading or changing the condition must be synchronized. Otherwise the first thread might test the condition, then the second thread in an unsynchronized method changes the condition and calls notify that is ignored, then the first thread calls wait and misses the notification.

I still don't understand why notify must be synchronized. As you just said it is very much possibe that the first thread calls notify and the second thread that should now execute doesn't executes and instead a third thread executes and causes the data to be changed which is to be used by the second thread.

Otherwise the first thread might test the condition, then the second thread in an unsynchronized method changes the condition and calls notify that is ignored, then the first thread calls wait and misses the notification.

Here is the first thread synchronized? If yes then the second thread can not change the condition if the lock is obtained on the condition(which should be done) unless wait is called(or somehow the lock is released). Now when wait() has been called then the second unsynchronized thread's notify should be acknowledged.
In case the first thread is not synchronized then the condition can change anytime during the course of the execution of the program.
I am attaching an application that does the following :
1. Producer produces the output. Producer is synchronized.
2. Consumer should consume the output. Consumer is synchronized.
3. Sometimes the hijacker steps in and changes the output. Hijacker is not synchronized.
What should happen is producer should produce and then issue a wait. Then consumer should consume and then it should also issuse a wait and notify the producer. But sometimes what happens is hijacker thread comes in between and changes the output to something else. This happens when producer has produced and is waiting for consumer for consume.
But I don't understand why hijacker though having a priority of 10 only comes into play a very limited no. of times. So you may have to run this application a few times before actually getting to the desired output.

public class ThreadCheck
{
String str="";
boolean producemore=true;
boolean tobeconsumed=false;
boolean notagain=true;


public static void main(String args[])
{
Thread t_cons,t_prod,t_hijack;
ThreadCheckmain_tc =new ThreadCheck();

prod p=new prod(main_tc);
cons c=new cons(main_tc);
hijack h=new hijack(main_tc);

t_cons=new Thread(c);
t_prod=new Thread(p);
t_hijack=new Thread(h);

t_prod.start();
t_cons.start();
t_hijack.start();
t_hijack.setPriority(10);
t_cons.setPriority(1);

}
}
class prod implements Runnable
{
ThreadCheck tc;
static int i=0;
prod()
{
}

prod(ThreadCheck ctc)
{
tc = ctc;
}
public void producer()
{
synchronized(tc)
{
while (tc.producemore)
{
i++;
tc.str="Producer has produced the output"+i;
System.out.println("Producer : " + tc.str);
tc.producemore = false;
tc.tobeconsumed=true;
tc.notifyAll();
try
{
tc.wait();
}
catch(InterruptedException e){}
}
}
}

public void run()
{
producer();
}
}
class cons implements Runnable
{
ThreadCheck tc;

cons()
{
}

cons(ThreadCheck ctc)
{
tc = ctc;
}
public void consumer()
{
synchronized(tc)
{
while (tc.tobeconsumed)
{
System.out.println("consumer :" + tc.str);
try
{
Thread.sleep(1000);
}
catch(InterruptedException e){}

tc.producemore = true;
tc.tobeconsumed=false;
tc.notifyAll();
try
{
tc.wait();
}
catch(InterruptedException e){}
}
}
}

public void run()
{
consumer();
}
}
class hijack implements Runnable
{
ThreadCheck tc;

hijack()
{
}

hijack(ThreadCheck ctc)
{
tc = ctc;
}

public void run()
{
while(tc.tobeconsumed)
{
if(tc.notagain)
{
tc.str="No boolean var. value changed though that can be done.";
tc.notagain=false;
break;
}
}
}
}

[Marlene Miller]

Hi Anupam. I am getting NullPointerExceptions when I add print statements to class hijack.
Exception in thread "main" java.lang.NullPointerException
at java.lang.Thread.setPriority(Thread.java:882)
at ThreadCheck.main(Test59.java:18)
Then I removed code that does not affect the exception. Do you also get a NullPointerException?

class ThreadCheck{
    boolean tobeconsumed=false;
    public static void main(String args[])    {
        Thread t_cons,t_prod,t_hijack;
        hijack h=new hijack();
        t_cons=new Thread();
        t_prod=new Thread();
        t_hijack=new Thread(h);
        t_prod.start();
        t_cons.start();
        t_hijack.start();
        t_hijack.setPriority(10);
        t_cons.setPriority(1);
    }
}
class hijack implements Runnable{
    ThreadCheck tc;
    hijack() {}
    hijack(ThreadCheck ctc)    { tc = ctc;    }
    public void run()    {
        System.out.println("hijack run()"); \\ I add this line
        while(tc.tobeconsumed) {
            System.out.println("hijack"); \\ I added this line
        }
    }
}

hijack run()
java.lang.NullPointerException
at hijack.run(Test59.java:26)
at java.lang.Thread.run(Thread.java:536)

[Anupam Sinha]

Had to modify the output because probably : and P were being considered as a smiley( ) and no more than 8 are allowed.
Outputs that I got :

hijack run()
Producer : Producer has produced the output1
consumer : Producer has produced the output1
Producer : Producer has produced the output2
consumer : Producer has produced the output2
Producer : Producer has produced the output3
consumer : Producer has produced the output3
Producer : Producer has produced the output4
consumer : Producer has produced the output4
Producer : Producer has produced the output5
consumer : Producer has produced the output5
Producer : Producer has produced the output6
consumer : Producer has produced the output6

This output is not from start

hijack
hijack
hijack
hijack
hijack
hijack
hijack
hijack
hijack
hijack
Producer : Producer has produced the output2
consumer : Producer has produced the output2
Producer : Producer has produced the output3
consumer : Producer has produced the output3
Producer : Producer has produced the output4
consumer : Producer has produced the output4
Producer : Producer has produced the output5
consumer : Producer has produced the output5
Producer : Producer has produced the output6
consumer : Producer has produced the output6
Producer : Producer has produced the output7
consumer : Producer has produced the output7
Producer : Producer has produced the output8
consumer : Producer has produced the output8

There were other outputs as well. But were mainly variations of the above outputs.
I only got the java.lang.NullPointerException only twice. I ran the program 20 times or so. Try this put t_hijack.setPriority(10); before t_hijack.start();.
As follows

t_hijack.setPriority(10);
t_hijack.start();

[Marlene Miller]

Ramesh, how would you like a really nice and short answer to your question? I found this in Doug Lea's Concurrent Programming in Java:
"Because of the way in which wait sets interact with locks, the methods wait, notify, and notifyAll may be invoked only when the synchronized lock is held on their targets."
(Well... what exactly does he mean by "the way"?)
[ July 17, 2003: Message edited by: Marlene Miller ]