How do Clojure futures and promises differ?

Question

Both futures and promises block until they have calculated their values, so what is the difference between them?

Answer 1

There are already excellent answers so only adding the "how to use" summary:

Both

Creating promise or future returns a reference immediately. This reference blocks on @/deref until result of computation is provided by other thread.

Future

When creating future you provide a synchronous job to be done. It's executed in a thread from the dedicated unbounded pool.

Promise

You give no arguments when creating promise. The reference should be passed to other 'user' thread that will deliver the result.

Answer 2

In Clojure, promise, future, and delay are promise-like objects. They all represent a computation that clients can await by using deref (or @). Clients reuse the result, so that the computation is not run several times.

They differ in the way the computation is performed:

• future will start the computation in a different worker thread. deref will block until the result is ready.

• delay will perform the computation lazily, when the first client uses deref, or force.

• promise offers most flexibility, as its result is delivered in any custom way by using deliver. You use it when neither future or delay match your use case.

Answer 3

Both Future and Promise are mechanisms to communicate result of asynchronous computation from Producer to Consumer(s).

In case of Future the computation is defined at the time of Future creation and async execution begins "ASAP". It also "knows" how to spawn an asynchronous computation.

In case of Promise the computation, its start time and [possible] asynchronous invocation are decoupled from the delivery mechanism. When computation result is available Producer must call deliver explicitly, which also means that Producer controls when result becomes available.

For Promises Clojure makes a design mistake by using the same object (result of promise call) to both produce (deliver) and consume (deref) the result of computation. These are two very distinct capabilities and should be treated as such.

Answer 4

Firstly, a Promise is a Future. I think you want to know the difference between a Promise and a FutureTask.

A Future represents a value that is not currently known but will be known in the future.

A FutureTask represents the result of a computation that will happen in future (maybe in some thread pool). When you try to access the result, if the computation has not happened yet, it blocks. Otherwise the result is returned immediately. There is no other party involved in the computing the result as the computation is specified by you in advance.

A Promise represents a result that will be delivered by the promiser to the promisee in future. In this case you are the promisee and the promiser is that one who gave you the Promise object. Similar to the FutureTask, if you try to access the result before the Promise has been fulfilled, it gets blocked till the promiser fulfills the Promise. Once the Promise is fulfilled, you get the same value always and immediately. Unlike a FutureTask, there is an another party involved here, one which made the Promise. That another party is responsible for doing the computation and fulfilling the Promise.

In that sense, a FutureTask is a Promise you made to yourself.

Answer 5

Answering in Clojure terms, here are some examples from Sean Devlin's screencast:

(def a-promise (promise))
(deliver a-promise :fred)

(def f (future (some-sexp)))
(deref f)

Note that in the promise you are explicitly delivering a value that you select in a later computation (:fred in this case). The future, on the other hand, is being consumed in the same place that it was created. The some-expr is presumably launched behind the scenes and calculated in tandem (eventually), but if it remains unevaluated by the time it is accessed the thread blocks until it is available.

---

edited to add

To help further distinguish between a promise and a future, note the following:

promise

1. You create a promise. That promise object can now be passed to any thread.
2. You continue with calculations. These can be very complicated calculations involving side-effects, downloading data, user input, database access, other promises -- whatever you like. The code will look very much like your mainline code in any program.
3. When you're finished, you can deliver the results to that promise object.
4. Any item that tries to deref your promise before you're finished with your calculation will block until you're done. Once you're done and you've delivered the promise, the promise won't block any longer.

future

1. You create your future. Part of your future is an expression for calculation.
2. The future may or may not execute concurrently. It could be assigned a thread, possibly from a pool. It could just wait and do nothing. From your perspective you cannot tell.
3. At some point you (or another thread) derefs the future. If the calculation has already completed, you get the results of it. If it has not already completed, you block until it has. (Presumably if it hasn't started yet, derefing it means that it starts to execute, but this, too, is not guaranteed.)

While you could make the expression in the future as complicated as the code that follows the creation of a promise, it's doubtful that's desirable. This means that futures are really more suited to quick, background-able calculations while promises are really more suited to large, complicated execution paths. Too, promises seem, in terms of calculations available, a little more flexible and oriented toward the promise creator doing the work and another thread reaping the harvest. Futures are more oriented toward automatically starting a thread (without the ugly and error-prone overhead) and going on with other things until you -- the originating thread -- need the results.