Futures and Promises - Blocking Vs Non-blocking Semantics

Blocking Vs Non-blocking Semantics

If the value of a future is accessed asynchronously, for example by sending a message to it, or by explicitly waiting for it using a construct such as when in E, then there is no difficulty in delaying until the future is resolved before the message can be received or the wait completes. This is the only case to be considered in purely asynchronous systems such as pure Actor languages.

However, in some systems it may also be possible to attempt to immediately or synchronously access a future's value. Then there is a design choice to be made:

• the access could block the current thread or process until the future is resolved (possibly with a timeout). This is the semantics of dataflow variables in the language Oz.
• the attempted synchronous access could always signal an error, for example throwing an exception. This is the semantics of remote promises in E.
• potentially, the access could succeed if the future is already resolved, but signal an error if it is not. This would have the disadvantage of introducing nondeterminism and the potential for race conditions, and does not appear to be a common design choice.

As an example of the first possibility, in C++11, a thread that needs the value of a future can block until it is available by calling the wait or get member functions. You can also specify a timeout on the wait using the wait_for or wait_until member functions to avoid indefinite blocking. If the future arose from a call to std::async then a blocking wait (without a timeout) may cause synchronous invocation of the function to compute the result on the waiting thread.