我能找到的Promises 和 Futures 的英文如下：（有人能给我中文解释吗？） Several past systems have taken advantage of batching to reduce domain-crossing overhead, for example Mercury call streams [Liskov 88b] and the X window system [Getty 90]. However, past systems have failed to deal adequately with the question of what to return to the client in place of the actual return value. X opts for the rather draconian solution of disallowing return values for batched calls. Under Mercury, the client receives a promise for the eventual result of the call, which at a later point it can explicitly claim to obtain the actual value. However, a promise is an inferior substitute for the actual result, because it cannot be used an argument to another remote call. Our approach improves on these past approaches both in its transparency to users and in its ability to batch interrelated calls. Futures were introduced in the parallel programming language Multilisp [Halstead 85]. However, they were used there to mask caller-callee parallelism on a multiprocessor system, rather than to batch calls in a serial system, as our scheme does. Because parallel futures introduce unrestricted concurrency, they can change the semantics of the client program, which is never the case with batched futures. Used unwisely, they can also increase the running time of a program, because of the overhead of the parallel fork and the additional tag checks required to check for futures, whereas batched futures never increase client running time. In a parallel system, a future might occur anywhere a basic value is expected, so the tag checks for futures “infect” the entire system. In our system, it is always the case that a future is evaluated by the time it is needed, eliminating the need for tag checks throughout the system.Introduction to Futures In general, a future can be viewed as a reference to the eventual result of a call. Like the actual result, it can be passed as an argument to other calls, included in data structures, and so forth. If the actual value referred to by the future is required and not yet computed, the client waits until it is available. Futures were introduced in the parallel programming language Multilisp to hide caller-callee parallelism, but we use them for a different reason: to defer calls so that they can be batched.
Several past systems have taken advantage of batching to reduce domain-crossing
overhead, for example Mercury call streams [Liskov 88b] and the X window system
[Getty 90]. However, past systems have failed to deal adequately with the question of
what to return to the client in place of the actual return value. X opts for the rather
draconian solution of disallowing return values for batched calls. Under Mercury, the
client receives a promise for the eventual result of the call, which at a later point it can
explicitly claim to obtain the actual value. However, a promise is an inferior substitute for
the actual result, because it cannot be used an argument to another remote call. Our
approach improves on these past approaches both in its transparency to users and in its
ability to batch interrelated calls.
Futures were introduced in the parallel programming language Multilisp [Halstead 85].
However, they were used there to mask caller-callee parallelism on a multiprocessor
system, rather than to batch calls in a serial system, as our scheme does. Because parallel
futures introduce unrestricted concurrency, they can change the semantics of the client
program, which is never the case with batched futures. Used unwisely, they can also
increase the running time of a program, because of the overhead of the parallel fork and
the additional tag checks required to check for futures, whereas batched futures never
increase client running time. In a parallel system, a future might occur anywhere a basic
value is expected, so the tag checks for futures “infect” the entire system. In our system,
it is always the case that a future is evaluated by the time it is needed, eliminating the need
for tag checks throughout the system.Introduction to Futures
In general, a future can be viewed as a reference to the eventual result of a call. Like the
actual result, it can be passed as an argument to other calls, included in data structures,
and so forth. If the actual value referred to by the future is required and not yet
computed, the client waits until it is available. Futures were introduced in the parallel
programming language Multilisp to hide caller-callee parallelism, but we use them for a
different reason: to defer calls so that they can be batched.