Jump to navigation Jump to search Not to be confused with Futures define theory. The term promise was proposed in 1976 by Daniel P. Friedman and David Wise, and Peter Hibbard called it eventual. The terms future, promise, delay, and deferred are often used interchangeably, although some differences in usage between future and promise are treated below.
Specifically, when usage is distinguished, a future is a read-only placeholder view of a variable, while a promise is a writable, single assignment container which sets the value of the future. The original Baker and Hewitt paper described implicit futures, which are naturally supported in the actor model of computation and pure object-oriented programming languages like Smalltalk. The use of futures can dramatically reduce latency in distributed systems. Each statement needs a message to be sent and a reply received before the next statement can proceed.
Suppose, for example, that x, y, t1, and t2 are all located on the same remote machine. In this case, two complete network round-trips to that machine must take place before the third statement can begin to execute. All three variables are immediately assigned futures for their results, and execution proceeds to subsequent statements. Promise pipelining should be distinguished from parallel asynchronous message passing.
Promise pipelining also should not be confused with pipelined message processing in actor systems, where it is possible for an actor to specify and begin executing a behaviour for the next message before having completed processing of the current message. The promise represents the read-only view, and the resolver is needed to set the future’s value. 11 a std::future provides a read-only view. The value is set directly by using a std::promise, or set to the result of a function call using std::packaged_task or std::async. In the Dojo Toolkit’s Deferred API as of version 1. 5, a consumer-only promise object represents a read-only view. Resolving the value can be done via System.
Support for read-only views is consistent with the principle of least privilege, since it enables the ability to set the value to be restricted to subjects that need to set it. Some languages, such as Alice ML, define futures that are associated with a specific thread that computes the future’s value. Alice ML also supports futures that can be resolved by any thread, and calls these promises. This use of promise is different from its use in E as described above. In Alice, a promise is not a read-only view, and promise pipelining is unsupported.