Future与promise

future和promise起源于函数式编程和相关范例（如逻辑编程 ），目的是将值（future）与其计算方式（promise）分离，从而允许更灵活地进行计算，特别是通过并行化。后来，它在分布式计算中得到了应用 ，减少了通信往返的延迟。再后来，它变得更有用了，因为它允许以直接风格编写异步程序，而不是以连续传递风格的方式。

对future的使用可能是隐式的（任何对future的使用都会自动获得它的值，它就像是普通的引用一样）或显式的（用户必须调用函数来获取值，例如Java中的java.util.concurrent.Future或java.util.concurrent.CompletableFuture的get方法）。获得一个显式的future的值可以称为stinging或forcing。显式future可以作为库来实现，而隐式future则通常作为语言的一部分来实现。

最初的Baker和Hewitt论文描述了隐式future，它们在演员模型和纯面向对象编程语言（如Smalltalk）中自然得到支持。Friedman和Wise的论文只描述了显式的future，可能反映了在老旧硬件上有效实施隐式future的困难。难点在于老旧硬件不能处理原始数据类型（如整数）的future。例如，add指令不会处理3 + future factorial(100000) 。在纯演员模型或面向对象语言中，这个问题可以通过发送future factorial(100000)消息+[3]，它要求future自己加3并返回结果。请注意，无论factorial(100000)何时完成计算，消息传递方法都可以工作，而且不需要任何sting或force。

在分布式系统中使用future可以显著地减少延迟。例如，future让promise流水线成为了可能，[5][6] 就像在E语言和Joule语言中实现的那样，在Argus语言中这也被称为call-stream[7]。

考虑一个涉及常规远程过程调用的表达式，例如：

 t3 := ( x.a() ).c( y.b() )

可以扩展为

 t1 := x.a();
 t2 := y.b();
 t3 := t1.c(t2);

每个语句需要发送一条消息，并在下一个语句可以继续之前收到一个答复。例如，假设x、y、t1和t2都位于同一台远程机器上。在这种情况下，在开始执行第三条语句之前，必须对该机器进行两次完整的网络往返。然后，第三条语句将引起另一个到同一个远程机器的往返。

使用future，上面的表达式可以写成

 t3 := (x <- a()) <- c(y <- b())

可以扩展为

 t1 := x <- a();
 t2 := y <- b();
 t3 := t1 <- c(t2);

这里使用的语法是E语言的语法，其中x <- a()表示将消息a()异步发送给x。所有三个变量都会立即为其结果分配future，执行过程将继续进行到后面的语句。之后尝试解决t3的值可能会导致延迟；但是，流水线操作可以减少所需的往返次数。如果与前面的示例一样，x、y、t1和t2都位于相同的远程机器上，则流水线实现可以用一次往返来计算t3，不必用三次。由于所有三条消息都指向同一远程计算机上的对象，因此只需要发送一个请求，只需要接收一个包含结果的响应。另请注意，即使t1和t2位于不同机器上，或者位于与x或y不同的机器上，发送t1 <- c(t2)也不会阻塞。

promise流水线应与并行异步消息传递区分开来。在支持并行消息传递但不支持流水线操作的系统中，上面示例中的消息发送x <- a()和y <- b()可以并行进行，但发送t1 <- c(t2)将不得不等到t1和t2都被接收，即使x、y、t1和t2在同一个远程机器上。在涉及许多消息的更复杂情况下，流水线的相对延迟优势变得更大。

promise流水线操作也不应与演员系统中的流水线消息处理相混淆，在这种系统中，可以演员在完成当前消息的处理之前指定并开始执行下一个消息的行为。

在某些编程语言（如Oz\E和AmbientTalk）中 ，可以获得未来的只读视图 ，该视图允许在resolve后读取其值，但不允许resolve它：

• 在Oz语言中，

!!运算符用于获得只读视图

• 在E语言和AmbientTalk中，future由一对称为promise/resolver对的值表示。promise表示只读视图，需要resolver来设置future的值。
• 在C++11中，std::future提供了一个只读视图。该值通过使用std::promise直接设置，或使用std::packaged_task或std::async设置为函数调用的结果。
• 在Dojo Toolkit的1.5版本的Deferred API中， 仅限consumer的promise对象表示只读视图。[8]
• 在Alice ML中，future提供只读视图 ，而promise包含future和resolve future的能力[9][10]
• 在.NET 4.0中，System.Threading.Task.Task<T>表示只读视图。解析值可以通过System.Threading.Task.TaskCompletionSource<T>来完成。

对只读视图的支持符合最小特权原则，因为它允许将值设置为仅限于需要设置该值的主体。在同样支持流水线的系统中，异步消息的发送方（包括结果）接收结果的只读承诺promise，消息的目标接收resolver。

某些语言（如Alice ML ）定义了与计算future值的特定线程相关联的future。[10] 这种计算可以在创建future时及早开始，或者在首次需要其值时懒惰地开始。在延迟计算的意义上，懒惰的future类似于thunk 。

Alice ML还支持可由任何线程解决的future，并调用这些promise。[9] promise的这种使用不同于上文所述的在E语言中的使用。在Alice中，promise不是只读视图，并且不支持promise流水线操作。相反，对于future未来，包括与promise相关的future，流水线是自然而然地发生的。

如果future的值是异步访问的，例如通过向它发送消息，或者通过使用类似于E语言中的when的构造显式地等待它，那么在收到消息或完成等待之前，推迟到future得到resolve没有任何困难。这是在纯异步系统（如纯演员语言）中唯一需要考虑的情况。

然而，在某些系统中，还可能尝试立即或同步访问未来的值。这样的话就需要做出一个设计选择：

• 访问权限可能会阻塞当前线程或进程，直到future得到resolve（可能需要超时）。这是Oz语言中数据流变量的语义。
• 尝试同步访问总是会发出错误信号，例如抛出异常 。这是E语言中远程promise的语义。 [11]
• 如果future已经resolve，则访问可能成功，但如果未resolve，则发出错误信号。这样做的缺点是引入了不确定性和潜在的竞争条件，这似乎是一种不常见的设计选择。

作为第一种可能性的示例，在C++11中 ，需要future值的线程可以通过调用wait()或get()成员函数来阻塞，直到可用为止。您还可以使用wait_for()或wait_until()成员函数指定等待超时，以避免无限期阻塞。如果future对std::async的调用，那么阻塞等待（没有超时）可能导致函数的同步调用以计算等待线程上的结果。

future是Event（同步原语）的特例，只能完成一次。通常，event可以重置为初始空状态，因此可以根据需要多次完成。[12]

I-var（如在语言Id中）是具有上面定义的阻塞语义的future。I-structure是包含I-var的数据结构。可以使用不同值多次设置的相关同步构造称为M-var。M-var支持采用或放置当前值的原子操作，其中取值还将M-var设置回其初始空状态。 [13]

并发逻辑变量与future类似，但是通过合一更新，与逻辑编程中的逻辑变量相同。因此，它可以多次绑定到可合一的值，但不能设置回空或unresolved状态。Oz的数据流变量充当并发逻辑变量，并且还具有上面提到的阻塞语义。

并发约束变量是并发逻辑变量的一般化，以支持约束逻辑编程：约束可以多次缩小，表示可能值的较小集合。通常，有一种方法可以指定每当约束进一步缩小时应该运行的hunk；这是支持约束传播所必需的。

通过在创建future的同时创建一个计算值的线程，可以在非线程特有的promise中直接实现及早求值的线程特有的future。在这种情况下，future将只读视图返回给客户端，以便仅让新创建的线程能够解决这个future。

要在非线程特有的promise中实现隐式延迟线程特有的promise（比如由Alice ML提供），需要一种机制来确定何时首先需要future的值（例如，Oz中的WaitNeeded构造[14] ）。 如果所有值都是对象，那么实现透明转发对象的能力就足够了，因为发送给转发器的第一条消息表明需要future的值。

假定系统支持消息传递，通过让resolve线程向future自己的线程发送消息，可以在线程特有的future中实现非线程特有的future。但是，这可以被视为不必要的复杂性。在基于线程的编程语言中，最具表现力的方法似乎是提供非线程特有的future，只读视图以及WaitNeeded构造或支持透明转发的混合。

future的求值策略（可称为传future调用）是非确定性的：future的值将在创建future和使用其值之间的某个时间进行求值，但确切的时间不确定的，一次运行和另一次运行的求值时间会不一样。计算可以在创建future时开始（及早求值），或者仅在实际需要值时开始（懒惰求值），并且可以在中途暂停，或在一次运行中执行。一旦future被赋值，它就不会在访问future的时候重新计算；这就像传需求调用时使用的记忆化。

懒惰future是确定性具有惰性求值评估语义的future：future值的计算在首次需要时开始，与传需要调用一样。懒惰future在求值策略默认不是懒惰求值的语言中使用。例如，在C++11中，可以通过将std::launch::deferred启动策略传递给std::async以及计算值的函数来创建这种惰性future。

在演员模型中，形式为future <Expression>的表达式由它对Eval消息（环境为E，客户为C）的响应方式定义：future表达式通过向客户C发送新创建的演员来响应Eval消息F （计算<Expression>的响应的代理）作为返回值，与此同时向<Expression>发送环境E和客户C的Eval消息。F的默认行为如下：

• 当F收到请求R时，它会通过评估<Expression>继续检查它是否已收到响应（可以是返回值或抛出异常），如下所示：
  1. 如果它已经有响应V，那么
     • 如果V是返回值，则发送请求R.
     • 如果V是一个异常，那么就会把这个异常抛给请求R的客户。
  2. 如果它还没有响应，则R存储在F内的请求队列中。
• 当F从评估<Expression>接到响应V时，则V存储在F中
  • 如果V是返回值，则将所有排队的请求发送到V.
  • 如果V是一个异常，那么就会把这个异常抛出给每个排队请求的客户。

但是，一些future可以通过特殊方式处理请求以提供更大的并行性。例如，表达式1 + future factorial(n)可以创建一个新的future，其行为类似于数字1+factorial(n) 。这个技巧并不总是有效。例如，以下条件表达式：

if m>future factorial(n) then print("bigger") else print("smaller")

会挂起，直到factorial(n)这个future已回应询问m是否大于其自身的请求。

future与promise构造首先在诸如MultiLisp和Act 1之类的编程语言中实现。在并发逻辑编程语言中使用逻辑变量进行通信非常类似于future。这些开始于Prolog with Freeze和IC Prolog，并成为真正的并发原语，包括关系语言、Concurrent Prolog、守卫霍恩子句（GHC）、Parlog、Strand、Vulcan、Janus、Oz-Mozart、Flow Java和Alice ML。来自数据流编程语言的单一赋值I-var ，源自Id并包含在Reppy的Concurrent ML中，非常类似于并发逻辑变量。

promise流水线技术（使用future来克服延迟）是Barbara Liskov和Liuba Shrira于1988年发明的[7]，由Mark S. Miller、Dean Tribble和Rob Jellinghaus在大约1989年的Xanadu项目中独立发明。[15]

promise一词是由Liskov和Shrira创造的，尽管他们通过名称call-stream引用了流水线机制，现在很少使用它。

Liskov和Shrira的论文中描述的设计以及Xanadu中的promise流水线的实现都有一个限制，即promise值不是一等的：一个参数，或者一个call或send返回的值不能直接成为一个promise （所以前面给出的promise流水线的例子，它使用一个发送的结果作为另一个发送的参数的承诺，在call-stream设计或Xanadu实现中不能直接表达）。似乎promise和call-stream从未在Argus的任何公开发布中实现， [16] Liskov和Shrira论文中使用的编程语言。Argus的开发在1988年左右停止了。[17] Xanadu实现的promise流水线仅在1999年Udanax Gold[18]的源代码发布时才公开发布，并且在任何已发布的文档中都没有解释过。[19] Joule和E的后续实现支持完全一等的promise和resolver。

一些早期的演员语言，包括Act系列，[20][21] 支持并行消息传递和流水线消息处理，但不支持promise流水线。（虽然技术上可以在前两个中实现最后一个功能，但没有证据表明Act语言这样做了。）

2000年之后，由于消息传递的请求-响应模型，future和promise在用户界面响应和web开发中的应用重新引起了人们的兴趣。现在有几种主流语言对future和promise都有语言支持，最着名的是Java 5中的FutureTask（2004年公布）[22]以及.NET 4.5中的async和await结构（2010年发布，2012年发布）[23][24]很大程度上受到F#的异步工作流程（可追溯到2007年[25]）的启发[26]。 随后被其他语言采用，特别是Dart（2014）[27]，Python（2015）[28]， Hack（HHVM）以及ECMAScript 7（JavaScript）、Scala和C++的草案。

支持future、promise、并发逻辑变量、数据流变量或I-vars的语言，无论是通过直接语言支持还是在标准库中，包括：

• FreeFuture 通过 FreeFuture页面存档备份，存于
• ABCL/f[29]
• Alice ML
• AmbientTalk（包含一流的解析器和只读promise）
• C ++，从C++11开始：std::future和std::promise
  • μC++
• • Compositional C++
• Crystal语言
• Dart（使用Future/Completer类[30]以及关键字await和async[27]）
• Elm语言通过Task模块[31]
• Glasgow Haskell （仅限I-vars和M-vars）
• Id （仅限I-vars和M-vars）
• Io[32]
• Java通过java.util.concurrent.Future或java.util.concurrent.CompletableFuture
  • Flow Java
• JavaScript（有限，从ECMAScript 6起支持）
• Lucid（仅限数据流）
• 一些Lisp
  • Clojure[33]
  • MultiLisp
• .NET通过Tasks
  • C#，自.NET 4.5起，[23]通过关键字async与await[24]
• Nim
• Oxygene
• Oz版本3 [34]
• Perl 6[35]
• Python concurrent.futures页面存档备份，存于, since 3.2,[36] as proposed by the PEP 3148页面存档备份，存于, and Python 3.5 added async and await[37]
• R（延迟计算的promise，仍然是单线程）
• Racket[38]
• Scala通过scala.concurrent包页面存档备份，存于
• Scheme
• Squeak Smalltalk
• Strand
• Swift （仅通过第三方库）
• Visual Basic 11（通过关键字Async和Await ）[24]

还支持promise流水线的语言包括：

• E
• Joule

基于非标准库的future实现：

• 对于Common Lisp：
  • Blackbird[39]
  • Eager Future2[40]
  • lparallel[41]
  • PCall[42]
• 对于C++：
  • Boost library[43]
  • Dlib[44]
  • Qt[45]
  • Seastar[46]
  • Folly[47]
  • POCO C++ Libraries (Active Results)[48]
• 对于C#和其他.NET语言：Parallel Extensions库
• 对于Groovy：GPars[49]
• 对于JavaScript：
  • Cujo.js'[50] when.js[51]提供符合Promises/A+[52] 1.1规范的promise
  • Dojo Toolkit提供promises[53]和Twisted方式延迟
  • MochiKit [54]受Twisted's Deferreds的启发
  • jQuery的Archived 2012-02-29 at WebCite Deferred Object基于CommonJS Promises/A页面存档备份，存于设计。
  • Angularjs[55]
  • node-promise[56]
  • Q，作者为Kris Kowal，符合Promises/A+ 1.1[57]
  • RSVP.js，符合Promises/A+ 1.1[58]
  • YUI的[59]promise类[60]符合Promises/A+ 1.0规范。
  • Bluebird，作者Petka Antonov[61]
  • Closure Library的promise页面存档备份，存于包符合Promises/A+规范。
  • 有关基于Promise/A+设计的更多实现，请参阅Promise/A+页面存档备份，存于列表。
• 对于Java：
  • JDeferred提供了与JQuery类似的deferred-promise API和行为。Deferred对象[62]
  • ParSeq[63]提供task-promise API，由LinkedIn维护，适用于异步流水线和分支
• 对于Objective-C：MAFuture[64][65]、RXPromise[66]、ObjC-CollapsingFutures[67]、PromiseKit[68]、objc-promise[69]、OAPromise[70]，
• 对于OCaml：Lazy模块实现了懒惰的显式期货[71]
• 对于Perl：Future[72]、Promises[73]、和Reflex[74]
• 对于PHP：React/Promise [75]
• 对于Python：
  • 内置实现[76]
  • pythonfutures[77]
  • Twisted's Deferreds[78]
• 对于R：
  • future，实现可扩展的future API与懒惰和及早同步和（多核或分布式）异步期货[79] [80]
• 对于Ruby：
  • Promise gem[81]
  • libuv gem，实现promise[82]
  • Celluloid gem，实现future[83]
  • future-resource[84]
• 对于Rust：
  • futures-rs[85]
• 对于Scala：
  • Twitter的util库[86]
• 对于Swift：
  • 异步框架，实现C#风格的async/非阻塞await[87]
  • FutureKit[88]、实现了Apple GCD的版本[89]
  • FutureLib，纯Swift 2库实现的Scala风格的future和promise与TPL风格的取消[90]
  • Deferred，纯Swift库，受到OCaml的Deferred启发[91]
  • BrightFutures[92]
• 对于Tcl：tcl-promise[93]

• 纤程
• Futex

• Concurrency patterns presentation页面存档备份，存于 given at scaleconf页面存档备份，存于
• Future Value页面存档备份，存于 and Promise Pipelining页面存档备份，存于 at the Portland Pattern Repository
• Easy Threading with Futures页面存档备份，存于 in Python