52

I am trying to get my head around Scala's promise and future constructs.

I've been reading Futures and Promises in Scala Documentation and am a bit confused as I've got a feeling that the concepts of promises and futures are mixed up.

In my understanding a promise is a container that we could populate value in a later point. And future is some sort of an asynchronous operation that would complete in a different execution path.

In Scala we can obtain a result using the attached callbacks to future.

Where I'm lost is how promise has a future?

I have read about these concepts in Clojure too, assuming that promise and future have some generic common concept, but it seems like I was wrong.

A promise p completes the future returned by p.future. This future is specific to the promise p. Depending on the implementation, it may be the case that p.future eq p.

val p = promise[T]
val f = p.future
Jacek Laskowski
  • 72,696
  • 27
  • 242
  • 420
nish1013
  • 3,658
  • 8
  • 33
  • 46
  • 1
    In clojure a future is a function executed in a separate thread, with a handle that can be referenced to access the return value if available; a promise in clojure is a placeholder that will be dereferencable to get a variable once some value has been delivered to it. I don't think either of these has much to do with scala. – noisesmith Sep 23 '13 at 13:49
  • 1
    So there is no consistent conceptual definition for future and promise constructs in programming languages ?? – nish1013 Sep 23 '13 at 13:56
  • 1
    Maybe this will help http://stackoverflow.com/questions/13381134/what-are-use-cases-of-scala-promise/13388618#13388618 – Marius Danila Sep 23 '13 at 14:09
  • 4
    I'd reduce/rephrase the question as "why couldn't `Future` and `Promise` be merged into a single concept/notion?". – Erik Kaplun Sep 23 '13 at 14:10
  • @nish1013 I had done a quick google about scala promises and futures and did not see a strong connection to the clojure definition, but I think subsub below make a great explanation of what these concepts have in common between clojure and scala. – noisesmith Sep 23 '13 at 14:57
  • 1
    Good interview question by the way. – om-nom-nom Sep 23 '13 at 14:57

3 Answers3

80

You can think of futures and promises as two different sides of a pipe. On the promise side, data is pushed in, and on the future side, data can be pulled out.

And future is some sort of an asynchronous operation that would complete in a different execution path.

Actually, a future is a placeholder object for a value that may be become available at some point in time, asynchronously. It is not the asynchronous computation itself.

The fact that there is a future constructor called future that returns such a placeholder object and spawns an asynchronous computation that completes this placeholder object does not mean that the asynchronous computation is called a future. There are also other future constructors/factory methods.

But the point I do not get is how promise has a future?

To divide promises and futures into 2 separate interfaces was a design decision. You could have these two under the same interface Future, but that would then allow clients of futures to complete them instead of the intended completer of the future. This would cause unexpected errors, as there could be any number of contending completers.

E.g. for the asynchronous computation spawned by the future construct, it would no longer be clear whether it has to complete the promise, or if the client will do it.

Futures and promises are intended to constrain the flow of data in the program. The idea is to have a future client that subscribes to the data to act on it once the data arrives. The role of the promise client is to provide that data. Mixing these two roles can lead to programs that are harder to understand or reason about.

You might also ask why the Promise trait does not extend Future. This is another design decision to discourage programmers from blindly passing Promises to clients where they should upcast the Promise to Future (this upcast is prone to be left out, whereas having to explicitly call future on the promise ensures you call it every time). In other words, by returning a promise you are giving the right to complete it to somebody else, and by returning the future you are giving the right to subscribe to it.

EDIT:

If you would like to learn more about futures, Chapter 4 in the Learning Concurrent Programming in Scala book describes them in detail. Disclaimer: I'm the author of the book.

axel22
  • 32,045
  • 9
  • 125
  • 137
  • so future is a container where value would be available in the future eventually and promise is for fulfilling promise by placing a value ? A future can be completed by fulfilling a promise? – nish1013 Sep 23 '13 at 15:40
  • 2
    Yes - promise is an object into which the value (or an error) can be put. Future corresponding to a particular promise will be completed once that promise is completed. Even the `future` construct for asynchronous computation has a hidden promise under the hood - but a client never sees it to prevent him from completing it. – axel22 Sep 23 '13 at 15:43
  • perfect ! many thanks for this clarification. One last bit , a future does not have to be used in asynchronous context always and also promise ? Even there would be little use in such a usage . Just wanted to ensure that promise/ future concept is nothing to do with synchronous/asynchronous concepts even though in practical they will be much usable when use within an asynchronous context. – nish1013 Sep 23 '13 at 15:52
  • 3
    That's right - you could use promises and futures in a singlethreaded context, where you e.g. alternate between various coroutines that have different access privileges to the future/promise object. – axel22 Sep 23 '13 at 16:35
  • 10
    Love the last sentence, "by returning a promise you are giving the right to complete it to somebody else, and by returning the future you are giving the right to subscribe to it", and I think it is valid for the ONE that creates the future/promise as well. – lcn Dec 15 '13 at 22:06
  • 4
    This comment is what should be on http://docs.scala-lang.org/overviews/core/futures.html – Jaka Jančar Dec 01 '14 at 17:28
18

The difference between the two is that futures are usually centered around the computation while promises are centered around data.

It seems your understanding matches this, but let me explain what I mean:

In both scala and clojure futures are (unless returned by some other function/method) created with some computation: 

// scala
future { do_something() }

;; clojure
(future (do-something))

In both cases the "return-value" of the future can only be read (without blocking) only after the computation has terminated. When this is the case is typically outside the control of the programmer, as the computation gets executed in some thread (pool) in the background.

In contrast in both cases promises are an initially empty container, which can later be filled (exactly once): 

// scala
val p = promise[Int]
...
p success 10 // or failure Exception()

;; clojure
(def p (promise))
(deliver p 10)

Once this is the case it can be read.

Reading the futures and promises is done through deref in clojure (and realized? can be used to check if deref will block). In scala reading is done through the methods provided by the Future trait. In order to read the result of a promise we thus have to obtain an object implementing Future, this is done by p.future. Now if the trait Future is implemented by a Promise, then p.future can return this and the two are equal. This is purely a implementation choice and does not change the concepts. So you were not wrong! In any case Futures are mostly dealt with using callbacks.

At this point it might be worthwhile to reconsider the initial characterization of the two concepts:

Futures represent a computation that will produce a result at some point. Let's look at one possible implementation: We run the code in some thread(pool) and once its done, we arrange use the return value to fulfill a promise. So reading the result of the future is reading a promise; This is clojure's way of thinking (not necessarily of implementation).

On the other hand a promise represents a value that will be filled at some point. When it gets filled this means that some computation produced a result. So in a way this is like a future completing, so we should consume the value in the same way, using callbacks; This is scala's way of thinking.

subsub
  • 1,857
  • 10
  • 21
7

Note that under the hood Future is implemented in terms of Promise and this Promise is completed with the body you passed to your Future:

def apply[T](body: =>T): Future[T] = impl.Future(body)  //here I have omitted the implicit ExecutorContext

impl.Future is an implementation of Future trait:

def apply[T](body: =>T)(implicit executor: ExecutionContext): scala.concurrent.Future[T] =
{
  val runnable = new PromiseCompletingRunnable(body)
  executor.prepare.execute(runnable)
  runnable.promise.future
}

Where PromiseCompletingRunnable looks like this:

class PromiseCompletingRunnable[T](body: => T) extends Runnable {
val promise = new Promise.DefaultPromise[T]()

override def run() = {
  promise complete {
    try Success(body) catch { case NonFatal(e) => Failure(e) }
  }
} }

So you see even though they are seperate concepts that you can make use of independently in reality you can't get Future without using Promise.

goral
  • 1,275
  • 11
  • 17