Question

This might be controversial, but I just realized I very seldom use wait and notify directly. Instead, I use some higher-level construct from the java.util.concurrent package. Are there use cases where wait and notify are the only solution or should they only be used when building higher-level constructs?

Answer 1

Are there use cases where wait and notify are the only solution or should they only be used when building higher-level constructs?

They should only be used when building higher-level constructs. If you have a case where the existing higher-level constructs don’t solve your problem, you don’t want to revert to wait/notify; you want to design a higher-level construct that solves your problem. You may implement it with wait/notify.

For example, I once had a problem that required concurrent execution of a collection of tasks with hierarchical dependencies, where the dependency conditions involved a combination of conjunction (“and”) and disjunction (“or”). I.e., there were cases where one task’s condition was “Task A is done and Task B is done,” cases where it was “Task A is done or Task B is done,” and various combinations of these (e.g., “Task A is done, and either Task B or Task C is done”).

So I wrote a small utility library that provided an interface for clients to submit collections of tasks annotated with their conditions, submitted these tasks to an Executor as soon as their preconditions were met, and monitored task completion to kick off newly eligible tasks. Some of that was implemented using java.util.concurrent (mainly Executor and Semaphore), but other parts involved using wait/notify (the “coordinator” thread is notified of task completion with wait/notify).

So the code ended up much easier to understand and troubleshoot, and later we found other uses for the same task coordinator library.