Waiting for an event in Java - how hard is it?

Question

I have a thread that updates it's state from time to time and I want a second thread to be able to wait for the first thread to be done. Something like this:

Thread 1:
    while(true) {
        ...do something...
        foo.notifyAll()
        ...wait for some condition that might never happen...
        ...
    }

Thread 2:
    ...
    foo.wait();
    ...

Now this looks nice and all unless Thread 1's notifyAll() runs before Thread 2's wait(), in which case Thread 2 waits until Thread 1 notifies again (which might never happen).

My possible solutions:

a) I could use a CountDownLatch or a Future, but both have the problem that they inherently only run once. That is, in Thread 1's while loop, I would need to create a new foo to wait for each time and Thread 2 would need to ask which foo to wait for. I have a bad feeling about simply writing

while(true) {
   foo = new FutureTask(); 
   ...
   foo.set(...);
   ...wait for a condition that might never be set...
   ...
}

as I fear that at foo = new FutureTask(), what happens when someone waited for the old foo (for "some reason", set was not called, e.g. a bug in the exception handling)?

b) Or I could use a semaphore:

class Event {
   Semaphore sem;
   Event() { sem = new Semaphore(1); sem . }
   void signal() { sem.release(); }
   void reset() { sem.acquire(1); }
   void wait() { if (sem.tryAcquire(1)) { sem.release(); } }
}

But I fear that there is some race condition, if multiple threads are wait()ing for it while another one signal()s and reset()s.

Question:

Is there nothing in the Java API that resembles the Windows Event behaviour? Or, if you despise Windows, something like golang's WaitGroup (i.e. a CountDownLatch that allows countUp())? Anything?

How to do it manually:

Thread 2 cannot simply wait because of spurious wakeup and in Java there is no way to know why Object.wait() returned. So I need a condition variable that stores whether the event is signalled or not. Thread 2:

synchronized(foo) {
    while(!condition) {
        foo.wait();
    }
}

And Thread 1 of course sets condition to true in a synchronized block. Thanks to weekens for the hint!

Is there an existing class that wraps that behaviour?

Or do I need to copy and paste the code all over?

Answer 1

It is standard practice to change some state when performing notifyAll and to check some state when performing wait().

e.g.

boolean ready = false;

// thread 1
synchronized(lock) {
    ready = true;
    lock.notifyAll();
}


// thread 2
synchronized(lock) {
    while(!ready) 
        lock.wait();
}

With this approach, it doesn't matter if thread 1 or thread 2 acquires the lock first.

Some coding analysis tools will give you a warning if you use notify or wait without setting a value or checking a value.

Answer 2

You could use a wait() with timeout, in which case you are not risking to wait forever. Also note that wait() may return even if there was no notify() at all, so, you'll need to wrap your wait inside some conditioned loop. That's the standard way of waiting in Java.

synchronized(syncObject) {
    while(condition.isTrue()) {
        syncObject.wait(WAIT_TIMEOUT);
    }
}

(in your Thread 2)

Edit: Moved synchronized outside the loop.

Answer 3

The simplest way is just to say

firstThread.join();

This will be blocking until the first thread is terminated.

But you can implement the same using wait/notify. Unfortunately you have not posted your real code fragments but I guess that if wait does not exit when you call notify it happens because you did not put both into synchronized block. Pay attention that the "argument" of synchronized block must be the same for wait/notify pair.

Answer 4

I'd use a BlockingQueue between the two threads. Using wait and notify is so 5 minutes ago ;)

enum Event {
  Event,
  Stop;
}

BlockingQueue<Event> queue = new LinkedBlockingQueue<Event>();

// Thread 1
try {
  while(true) {
    ...do something...
    queue.put(Event.Event);
    ...wait for some condition that might never happen...
    ...
  }
} finally {
  // Tell other thread we've finished.
  queue.put(Event.Stop};
}

// Thread 2
...
switch ( queue.take() ) {
  case Event:
       ...
       break;

  default:
       ...
       break;
}

Answer 5

Seems there is only ugly solutions. I solve it using AtomicBoolean as flag and some sleep to prevent high cpu usage and timeout for unexpected lost event...

Here my code: somewhere in thread class:

private static final int WAIT_DELAY_MS_HACK      = 5000; //ms
private static final AtomicBoolean NeedToExecute = new AtomicBoolean(false);

In working thread, that need to send wake signal:

public static final void SendSignalToExecute(){
    synchronized(NeedToExecute){
        NeedToExecute.set(true);
        NeedToExecute.notify();
    }
}

In the thread that must wait signal:

//To prevent infinite delay when notify was already lost I use WAIT_DELAY_MS_HACK in wait(). 
//To prevent false interruption on unknown reason of JM I use while and check of AtomicBoolean by NeedToExecute.get() in it.
//To prevent high CPU usage in for unknown persistant interruption in wait I use additional sleep():
while (!NeedToExecute.get()){ 
    synchronized(NeedToExecute){
        try {
            NeedToExecute.wait(WAIT_DELAY_MS_HACK); //if notify() was sent before we go into wait() but after check in while() it will lost forever... note that NeedToExecute.wait() releases the synchronized lock for other thread and re-acquires it before returning
        } catch (InterruptedException ex) { //here also may be sleep or break and return
        }
    }
    sleep(100); //if wait() will not wait - must be outside synchronized block or it may cause freeze thread with SendSignalToExecute()... :(
 }
 NeedToExecute.set(false); //revert back to reenter check in next iteration, but I use it for one waited thread it cycle "do ... wait" if you use multiple thread you need to synchronise somehow this revert