Futures and get() in Concurrent Tasks

In concurrent programs, one part of the program often starts work and another part needs the outcome of that work. The second part cannot always wait for the work to finish in the same place where it was started. It needs a way to ask for the result and a way for the result to be delivered when it is ready. This article looks at the pair of tools built for that job: the future, which is where a result will appear later, and the promise, which is how the result gets put there.

Keep one question in mind as you read: when a task finishes, who is responsible for putting the outcome somewhere, and who is responsible for taking it out? The answer is the core of this topic, and the sections below trace that handoff one step at a time.

A future is a place where a result will appear later. Someone has to put that result there, and someone else reads it out. The future is the reading side and offers get() to retrieve the result. The promise is the writing side, and its main job is to provide simple put operations that match the future's get(). The two halves are designed to fit together, so a result produced in one part of a program can be delivered to the future that another part is waiting on.

The names future and promise are historical. They do not describe the mechanics perfectly, so it helps to think of them as a pair of handles. The promise is the handle you use to send something in. The future is the handle you use to take it out. Whatever goes in through the promise is what comes out through the future.

The diagram below shows the order of events. The producing task performs a put on its promise. The promise stores the outcome in the future. Later, a separate reader calls get() on the future to take the outcome out. Read it as a relay: the put comes from the sending side, and the get comes from the receiving side.

Notice that the consumer's get() is the step that finally exposes the outcome. The consumer does not need to know how the producer did its work. It only needs the future, and the future only gets filled when the promise performs one of its put operations. The same order holds whether the put carried a value or an exception.

Suppose you hold a promise and need to send a result of type X to the future. You have exactly two options. You can pass a value, which is a normal result of type X. Or you can pass an exception, which reports that the work failed. The promise's operation for the first option is set_value(), and the operation for the second is set_exception(). Whichever you choose, the future receives it, and a later get() call is where the outcome becomes visible.

The value path is the ordinary case. The task finishes its work successfully and has a real result to give. It calls set_value() on the promise with that result, and the future now holds it.

Sometimes the work does not succeed. Instead of a value, the promise must carry an exception to the future, and the operation for that case is set_exception(). The purpose is the same as the value path, with a different payload. The future is still the place where the outcome is read, but the reader learns that something went wrong rather than receiving a normal result.

The source pack names a helper for the failure case: current_exception(). It refers to the exception that was caught. When a task has caught an error, current_exception() gives a way to point at that caught exception so that it can be passed along to the future. In other words, it is the bridge between the handling code and the promise.

This walkthrough is an original illustration built from the handoff described above. It shows the value path only. The failure path follows the same order, except that the producer calls set_exception() with a caught exception, and the consumer's get() reports that the work failed.