Wait state vs. blocked state ?

[Bob Graffagnino]

What is the difference between a Thread using wait/notify to wait for a shared resurce as opposed to the Thread going into a blocked state when the shared resource is in use?
For example:

class Book {
  public static final int EXAM_CRAM = 1;
  private boolean available = true;
  public Book() {}
  public Book( int id ) {}
  public synchronized void read(String readerName){
      System.out.println( readerName + " has started studying." );
      while( available == false ){
try{
          wait();
        }catch( InterruptedException ie ){
System.out.println( "Doh!  I've been interrupted!" );
    }
      }
      available = false;
      // flip pages, extract info, etc.
      available = true;
      System.out.println( readerName + " has finished studying." );
      notifyAll();
  } // read
} // Book

class Student extends Thread{
  String myName;
  Book myBook;
  public Student(){}
  public Student( Book b, String name ){
    myName = name;
    myBook = b;
  }

  public void run(){
    myBook.read( myName );
  }
} // Student

public class SchoolWithBudgetIssues{
public static void main( String[] args ){
Book b = new Book( Book.EXAM_CRAM );
Student tom = new Student( b, "Tom" );
Student dick = new Student( b, "Dick" );
Student harry = new Student( b, "Harry" );
tom.start();
dick.start();
harry.start();
} // main
} // SchoolWithBudgetIssues 

How would it differ if we made the Book's read() method:

public synchronized void read(String readerName){
      System.out.println( readerName + " has started studying." );
     
      // flip pages, extract info, etc.
      System.out.println( readerName + " has finished studying." );
  } // read

It seems to me that if wait/notify are used, the threads will go into a wait state if the book is being read by someone else.
If wait/notify are not used, the threads go into a blocked state.
What's the difference here???

[Valentin Crettaz]

Bob,
I have a very simple diagram showing the lifecycle of threads available here.
HIH

[Bob Graffagnino]

Your document implies that when notifyAll() is called, only one thread who obtains the lock goes to a ready state.
I thought that notifyAll() put all waiting threads into the ready state and which ever thread was chosen by the CPU to run would obtain the lock.
???

[Valentin Crettaz]

yes and the others return in the "seeking lock" state. Thank for your comment, I've changed it.
[ February 08, 2002: Message edited by: Valentin Crettaz ]

[Jose Botella]

In this example the wait and notify should be avoided. Because once executing the syncronized method the book is already in use,yes , but by the thread itself executing the method. Thus if the thread ever waits, it is for lending the book that alredy had. I guess that is not the goal. In fact it is enough to mark the method as synchronized and forget about the available flag, wait and notify.
There are two ways of synchronizing threads:
1) For sharing a common resource.
The intention is to avoid the access to a commom resource simultaneously by several threads. The program is an example of that.
2) For cooperating in a commom task.
A thread process until it reaches a point in which it can not go on. It must wait for another thread to process. This second thread runs untill it reaches a point in which it can not go on. It has already done the work that will allow the first thread to continue. Thus the second thread will notify the first one. An the process will repeat itself.
An example of such scenario can be found in the Java Tutorial at java.sun.com
It is called the producer-consumer scenario. One thread consumes what the other produces.

[Bob Graffagnino]

Let me see if I understand this correctly.
In the case of wait()/notifyAll() or wait()/notify():
When notify()/notifyAll() is called, one thread will go into the ready state.
In the case of a blocked thread (wait/notify is not used):
When a particular condition changes, all threads waiting on that condition will go to the ready state.

Assuming that's correct, why would a developer choose to code a thread's behavior one way over the other?
EDIT: I posted this before reading Jose's reply. Thinking.....
[ February 08, 2002: Message edited by: Bob Graffagnino ]

[Bob Graffagnino]

Thanks Jose, that makes sense.
It seems more clear to me if I consider a case of 2 Threads with different behavior that need the same object to do their work.
For instance:
class CookieMonster extends Thread{}
class BakerBob extends Thread{}
class CookieJar{}
CookieMonster needs a CookieJar to perform his method eatCookies().
BakerBob needs a CookieJar to perform his method putCookies().
CookieMonster can't get any cookies from the cookieJar if it's empty.
BakerBob doesn't want to try to put any cookies in the cookieJar while CookieMonster is eating from it (BakerBob could lose a hand!).
When CookieMonster has eaten all the cookies he yells, "More cookies, more cookies"!
When BakerBob hears this, he can (safely) grab the cookieJar and put more cookies in it. When he's done he yells, "The cookie jar is full", and quickly puts down the jar for fear of bodily harm.

Do I have the right idea here?

[Jose Botella]

Yes you got it.
Also a thread that is waiting can not notify itself or others. It needs to be notified by other thread. (Unless the overloaded wait is used, but we are not seeing a cooperative scenario then).

[Rajinder Yadav]

Bob, when we say a thread is blocked we mean that the thread is waiting for a lengthy operation to complete. A thread could block on a function call, for example a function may compressed a text-file, so the thread is said to be blocked on this function call, the only catch here is that function must be at the system level not the user level (like your source code is). So your program may ask to open a socket connection over the Internet, this will transfer your call from the user level to the system level, where the JVM will attempt to make a TCP/IP connection. This operation would take some amount of time, so you would say the thread is blocked at this point! In our case control would have been transfered from the user level to the system level which would be doing the actual low-level connection for you.
A call to wait() is different because the programmer has control when to suspend the thread, also unlike a blocked thread, a thread in the wait state is put to sleep, what this mean is it's gives up it CPU time slice until it's woken up again. A thread in the wait state will use virtually no CPU cycles, where as a blocked thread will continue to use CPU cycles just like a running thread.