Thread Synchronization

[Sri Bala]

What I understand about synchronizing threads is, the first thread executes the synchronized method or block and the other threads wait on the lock. Once a thread has done with its work, it has to do a notify or notifyAll on the lock and other threads get a chance. So, I thought without notify or notifyAll, other threads will wait for ever. I wrote a program without notify or notifyAll and it works. If threads wait and get notified automatically, why do we need wait, notify & notifyAll?

class MyThread extends Thread 
{
  public String str;
  MyThread(String str) { this.str = str; }
  private static Object printLock = new Object();
  public  void print(String str)
  {
    synchronized(printLock)
    {
      try 
      {
        while(!isInterrupted())
        {
          System.out.println(str);
          sleep(10);
        }
      }
      catch(InterruptedException e)
      {
         System.out.println("Bye... from "+str);
      }
    }
  }
  public void run()
  {
    print(str);
  }
}
public class Monitor1 {
  public static void main(String args[])
  {
    Thread t1 = new MyThread("Test1");
    Thread t2 = new MyThread("Test2");
    t1.start();
    t2.start();
    try 
    {
      Thread.sleep(100);
      t1.interrupt();
      Thread.sleep(100);
      t2.interrupt(); 
    }
    catch(Exception e)
    {
      System.out.println("Bye...");
    }
  }
}

[Andy Ceponis]

Im not 100% sure of a few lines in your example.
From what i can gather, you synchronized on a printlock object. But i dont see where that object is doing any work? But since im not sure what the while(!isInterrupted()) does, maybe that has something to do with it. The small programs ive written and worked with on threads need to have the wait, notify, and notifyall in the locks or synchronized methods/blocks of code. Im sure someone else can help much more on this, since everything i just said doesnt amount to much at all.

[This message has been edited by Andy Ceponis (edited March 22, 2001).]

[Jim Yingst]

You only need notify() or notifyAll() if you use the Object wait() method, which you don't in this program. When a thread waits only because it is unable to enter a synchronized block without the lock, that different from a wait(). If it's waiting for a lock, then it will keep trying until it gets the lock (or the program terminates), without needing any notification to retry. In fact, the wait() method was developed in part to remove the need for a thread to keep re-trying to get a lock. It's a way of saying "don't call us; we'll call you." The thread can instead go completely dormant until notified - that way it doesn't keep bothering the processor by repeatedly asking for a lock which is unavailable.
Andy - the printlock doesn't need to do any particular work; it's just a common reference point to make sure that no two threads are entering print() at the same time. I probably would have synchronized on System.out instead, just because that way I wouldn't have to create a new object for no other purpose. But it's perfectly valid to create an object whose only intended use is as a syncronization object. Often that makes it easier to understand its role - it it doesn't do anything else, it's easier to notice exactly what it is doing.

[Sri Bala]

If saving CPU time is the only reason, I guess wait & notifyAll functionality could have been built within the language, transparent to the programmers. I guess there should be a stronger reason for giving it to the programmer.

[Andy Ceponis]

Thanks Jim for clarifying that. I wasnt sure what was going on , and u made it clear.

[Sri Bala]

One more thing Andy. isInterrupted() is not my method. It's how a thread checks if it has been interrupted. It has to check for this as well as handle the InterruptedException. If the thread gets interrupted when in a loop, the former check finds it. If the thread is in wait() or sleep(), the exception is raised.

[Andy Ceponis]

Cool, thanks for the clarification. You can see im new to this....

[Rahul Rathore]

Originally posted by Sri Bala:
If saving CPU time is the only reason, I guess wait & notifyAll functionality could have been built within the language, transparent to the programmers. I guess there should be a stronger reason for giving it to the programmer.

Bala
Can you explain what you mean by saying that wait() and notifyAll() functionality could have been built within the language, transparent to programmers?
In fact wait() and notifyAll() are built within the language, that is why programmers can use them.
If they were transparent to programmers they would be of no use. Because when a thread must wait and when it must be notified is entirely determined by the PROGRAM LOGIC. Only the programmer can know the situation in which the thread must go into wait, and the situation when the waiting thread must be notified.
Take the classic producer-consumer thread example. In the simplest form, producer threads and consumer threads are running. The producer threads are regularly updating some value in a shared variable X, and the consumer thread are regularly retrieving the value stored in X.
At the first level- access to X must be synchronized- i.e. 2 threads- (2 consumers or 2 producers or 1 consumer+1producer) should not try to access simultaneously, because that may result in an indeterminate/inconsistent state.
At the next level - the program logic may require that producer should update only if the last update has been consumed, and the consumer should consume only if the update is new i.e. as yet unconsumed.
An inefficient way of implementing this logic would be to externally implement a busy loop where the threads are doing:-
while(!conditionSatified) {
acquire monitor on the shared object.
check if condition satisfied (update made/consumed)
if conditionSatisfied, produce/consume and break.
release monitor and continue loop if condition not satisfied.
}//end of while loop
An efficient way of doing the same thing is:-
acquire monitor on the shared object.
while(!conditionSatisfied) {
wait();
}
produce/consume;
notify();
release monitor
In the former inefficient method a busy loop is implementing to check if condition is satisfied. A busy loop by itself is loading the processor- and aggravating the load is the fact that lock/monitor has to be acquired in each loop. Thus Producer threads are uselessly competing for resources, even when the previous update has not yet been consumed, and similarly consumer threads are uselessly competing for resources even when no new update has been made.
Compare this with the efficient method. Here a thread acquires the monitor once- If condition is not satisfied, then it simply goes into wait() releasing the lock, confident that whenever another thread which does something which may change the condition conducively it would do notify()/notifyAll(). Of course after reviving from wait() the thread will again compete for a lock/monitor, but now it does so only when the situation has become promising (i.e. it is more likely to find the condition satisfied).
Thus in general terms a thread seeking a condition, will not continously/uselessly check for the condition, rather it will wait for a notification that the condition has arrived.
I think it is obvious by now, that only the programmer can know when to issue wait() and notify() because that is entirely determined by program logic. The wait() and notify() method are tools for efficient and consistent implementation of program logic. It would make no sense to hide those tools from the very person who can use them.

[Sri Bala]

Thanks Rahul. I understand the necessity of wait & notify's now. Thanks again for the effort.