A ''Future'' is a mechanism which can be used to provide values that will be ''resolved'' to another value asynchronously. Futures are similar to "promises" (see PromisePipelining). In some languages (e.g. AliceLanguage), both terms are used with a technical distinction between them, as described at http://en.wikipedia.org/wiki/Future_%28programming%29 .

A method/function can return a future to its caller, and continue to compute the value that the future will resolve to in another thread of control (e.g. as part of an ActiveObject as described in PatternOrientedSoftwareArchitectureTwo).

----
So if a method has an asynchronous invocation behavior, how to return one or more values from the method? Remember, when the invocation returns, the method might not have finished its calculation.

Instead of returning the value immediately (which is not possible), a placeholder for the value - a ''Future'' is returned. Once the method has calculated the value, the ''Future'' becomes ''resolved''. As long as the value is not available, the ''Future'' is ''unresolved''.

The ''Future'' provides a way to ask for the actual value. Two situations are possible:

	1. The ''Future'' has resolved already. That is, the method calculating the value has finished, and stored the result in the ''Future''. Asking for the ''Future's'' value will immediately give the result.

	2. The ''Future'' has not resolved. In this case, the current thread is blocked until the ''Future'' resolves. The current thread is effectively synchronised with the thread calculating the value.

What are the advantages of using a ''Future'' if accessing an unresolved ''Future'' will block the current thread anyhow? Well, the ''Future'' itself can be passed around in an application or stored. So as long as the program logic does not require immediate usage of the result, the current thread is not blocked. A combination of an ActiveObject and a ''Future'' can be used to achieve concurrency, whereby the threads are well confined (bound to) objects.

To the best of my knowledge, ''Futures'' first appeared in some concurrent Lisp dialects [the one usually cited is MultiLisp].

-- ThomasWeidenfeller

----
'''Languages supporting futures'''

With SharedStateConcurrency:
* OzLanguage
* AliceLanguage
* MultiLisp
* Luban? (http://www.lubankit.org/MultiThreadingTutorial.htm)

With MessagePassingConcurrency:
* IoLanguage
* JouleLanguage
* EeLanguage
* most other ActorLanguages (Act1/2/3, etc.)

-----
CategoryLanguageFeature