about wait() and notifyALL

[denis]

hi everyone i have a question about using wait and notifyALL()
i am very confused about these two which i have never been able to use.

as per the API
wait() = Causes current thread to wait until either another thread invokes the notify() method or the notifyAll().
does the above wait() means that the current thread will wait as the monitor has already been in use by another thread. and will continue until the thread using the monitor releases the lock through notifyALL().

notifyall() = is notify all the threads waiting on the monitor.

i would really appreciate if somebody could post a simple code on wait and notifyALL().

thanks in advance.
Denis

[Norm]

post a simple code on wait and notifyALL().

I did that just recently. Do a search for wait or notify.

It's in this thread:
Once again: waiting in a thread loop.

[Niveditha]

:) lots of examples in the net available do a google search.

[Mrs. Deswal]

Hi,

I have also problem using wait() and notifyAll(). My program gives error in simply using wait(). Please tell me.

[OrangeDog]

A MonitorStateException? You have to be synchronized on the object you're waiting on.

[neilcoffey]

First, don't worry -- practically the entire world doesn't know how to use wait/notify. One thing to consider is whether for what you're doing there's something else in the concurrency library that'll help you. For example, BlockingQueue is a better alternative to many typical uses (the "producer-consumer" pattern), and if you want to use it for a thread pool, consider using ThreadPoolExecutor.

OK, that said, the essential way it works is that you have some object which will act as the "message signaller". One or more threads will wait() on that object. That means they sit "waiting for a messge" telling them to wake up. Then at some point, another thread will call notify() or notifyAll() on that same object, which is what makes the waiting thread(s) wake up.

- notify() makes one random thread wake up; it's useful for implementing thread pools, where you have a stream of "jobs" coming in and you want "any available thread" to take the job
- notifyAll() wakes up all threads that were waiting on that object; it's useful in cases where all threads waiting on that object potentially need to be signalled.

Note that the notified thread(s) don't necessarily wake up immediately-- just when it's next "convenient" for the thread scheduler to let them run.

Both the waiter and the notifier must synchronize on the object. But while waiting, the waiter temporarily releases the lock, then re-acquires it when it is woken up.

You may be interested in various articles I've written on wait/notify on my web site. They're some of the most consulted articles on the site-- as I say, it seems the world in general is a bit mystified by wait/notify.

[neilcoffey]

Sorry, I should have given a concrete example. A typical case is you have a logging thread that sits waiting for strings to log. And then other threads post strings to that thread. So the logging thread's run method looks a bit like this. For clarity, I'm missing out exception handling (you need to catch interruptions, generally around the whole method code):

private List<String> messageQueue;
...
public void run() {
  while (!stopRequested) {
    String line;
    synchronized (messageQueue) {
      while (messageQueue.isEmpty()) {
        messageQueue.wait();
      }
      line = messageQueue.remove(0);
    }    
    log 'line'
  }
}

Notice we wait in a while loop: it's conceivable that wait() could "spuriously return" even though you haven't been notified. So we repeatedly check if there was actually a message posted to the queue.

Then when another thread wants to log a line, it calls a method such as this:

public void logLine(String line) {
  synchronized (messageQueue) {
    messageQueue.add(line);
    messageQueue.notifyAll();
  }
}

Here, we may as well use notifyAll() -- in general, it's best to use notifyAll() unless you know that the behaviour you want is to just wake up one random thread waiting on that object.

I should stress though, that wait/notify is largely obsolete for most purposes like this. As of Java 5, BlockingQueue is a generally much preferable alternative.

[OrangeDog]

It doesn't "spuriously return". If you've called notifyAll() then all waiting threads are going to wake up and only one is going to get the lock. You need the loop to put all the rest to sleep again.

[neilcoffey]

In this case, that's not really what the loop's for-- though obviously, it does have that function when there are competing threads for the object being removed (e.g. a thread pool).

Note that wait() really is defined as being allowed to spuriously wake up!

[OrangeDog]

Hmm, so it is. All the more reason to do concurrency carefully.

[Mrs. Deswal]

Hi,

I want to read some files by a thread & want to write them to another file by another thread. I want this in manner that one thread read a file in a stringbuffer and another thread write them in a file and then first thread read second file so on. I have file paths in a string array. Please provide me code if possible.

Thanks in advance.

[OrangeDog]

Did you address my previous suggestion?

[neilcoffey]

To do the one-thread-read, one-thread-write problem, the code is practically the code that I posted above, just instead of logging, the thread writes the string to a file, and the actual string posted to the "logging" thread is a string from the file. As I say, BlockingQueue is often a preferable alternative. There's some example code at this link that again is based around the idea of a logging thread, but is easily adapted to write the strings to a file.

[Mrs. Deswal]

yaah,

I have addressed your previous suggession. But i am not so much exprienced developer. So i was unable to do that.

Thanks.