Thread Synchronization Basics

Imagine you want to build your own blocking queue. In a blocking queue, a consumer that asks for an item does not fail when the queue is empty. Instead, it simply waits until an item arrives. To build one, you need a way to hold a thread in a waiting state until some event happens. That event is usually caused by a different thread, such as a producer adding an item to the queue. So the problem involves at least two threads: one that waits, and one whose action wakes it up.

This article explains the basic mechanism Java provides for that handoff: wait() and notify(). Both are instance methods of class Object, which means any object can be used to coordinate two threads. The rest of the article traces how that handoff works step by step, and then looks at the case where things go wrong.

The blocking queue is the most visible example, but it is not the only one. Any time one thread produces a result that another thread needs, the order of their work is constrained. The consuming thread cannot finish its computation until the result exists. It could repeatedly check whether the result is ready, but the source describes a cleaner approach: let the consuming thread stop and wait, and then wake it up when the result is ready.

Thread A in this pattern does not always wait. It waits only when its check finds that the result is not yet available. If the result already exists, the if condition is false, the call to wait() is skipped, and Thread A moves straight on to using the result. The pause is therefore conditional: it happens only when there is something to wait for.

The clearest way to understand the handoff is to follow the calls in time order. Two threads are involved. Thread A is the consumer that needs a result. Thread B is the thread that produces it. Both work on the same shared object, and wait() and notify() are called on that object.

The diagram reads as the life of one thread. The key detail is that the notification must target the same object that the waiting thread called wait() on. Thread A stays in the waiting state until notify() is called on that object, and it resumes only then.

A thread that calls wait() on an object sleeps until another thread calls notify() on that same object. So from the waiting thread's point of view, there are only two situations to track: it is running, or it is waiting. The transition from running to waiting is caused by reaching wait(). The transition back to running is caused by a notify() on the same object.

Notice that the thread does not move from waiting to running on its own. Something has to call notify() on the object it is waiting on. This is why the producing thread's action is the one that wakes the consumer.

The handoff only works when the notify() happens while the waiting thread is actually waiting. Calling notify() when no thread is waiting is not an error and has no effect. The signal does not wait around for a future wait() call. This is the failure mode that causes the handoff to go wrong.

Wait and notify are the building blocks behind patterns such as blocking queues. The source notes that these methods can be used internally to implement blocking queues, and that Java has other ways of solving the wait and notify problem. The reader does not need to know whether Java's standard blocking queue classes use these methods internally.