谢谢给位给我顶，但是我还是不明白
我能找到的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.
我能找到的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.
解决方案 »
免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货