Spawning Tasks on Separate Threads

When a task is spawned on a separate thread, the code that started it keeps running. The task may finish some time later, but the caller still needs its result. This creates a practical problem: how does a value produced on one thread get back to the code that needs it on another thread?

The source introduces futures and promises as the mechanism for this job. As you read, keep one question in mind throughout: at any moment, is the value already available, or is it still on its way? Most of the reasoning about futures and promises comes down to answering that question correctly.

Think of a task on a separate thread as a piece of work you hand to someone else. You do not get the answer back immediately. Instead, you receive a claim ticket that will be honored when the answer exists. The ticket is not the answer. It is the thing you can check and collect from later.

Because the value is produced on a separate thread, the future is the natural place to wait for that value and collect it once it is ready. Its purpose is narrow and specific: moving a result from a task back to the code that needs it. The future is the handle the caller holds. It is the thing the caller reads from.

A promise works together with a future for handling the task's return value. The useful way to keep the two ideas apart is this: the future is what you read from, and the promise is what the task uses to make the value available. Neither one is useful on its own in this pattern. The value travels from one to the other.

The relationship is a linked pair. The task running on a separate thread is connected to a promise, the promise is linked to a future, and the future returns the value to the caller. Reading the chain from left to right in terms of data flow: the task is where the value comes from, the promise is the channel that carries it, the future is the handle the caller holds, and the calling code is where the value is finally used.

The pair moves through a small number of states. It begins in a waiting state, in which the future has no value yet. The only change that moves it forward is the value being supplied through the promise. Once that happens, the future has something to return. Reading it is the final step. The diagram below traces these states in order.

Notice that the waiting state is the first state, and it is the one learners most often underestimate. Nothing has gone wrong while the future is waiting. Only the supply of the value through the promise moves the pair forward, and only reading the future completes the trace.

The value has a direction. It starts in the spawned task, moves through the promise, is held by the future, and is finally used by the calling code. The next diagram shows only that movement, without the state labels.

A useful check is to ask, at each arrow, whether the value has already crossed it. Before the task supplies the value, nothing has crossed the first arrow, so the future has nothing to return.

Once the task is spawned, the caller and the spawned task proceed on their own threads. The code that started the task keeps running, so the two threads move forward independently until the caller needs the result. The timeline below shows one possible ordering of these events. The order of the spawned task's finish relative to the caller's progress can vary, which is exactly why the caller must check whether the value is available before using it.