Futures are language constructs that improve concurrency in a natural and transparent way. A future is a place holder for a result of a concurrent computation [5]. Once the computation is complete and a result (called future value) is available, the placeholder is replaced by the result. Access to an unresolved future results in the caller being blocked, until the result becomes available. Results are only awaited when they are really needed which helps in improving the parallelization. Futures may be created transparently or explicitly. For explicit creation, specific language constructs are necessary to create the futures and to fetch the result. Transparent futures, on the other hand, are managed by the underlying middleware and the program syntax remains unchanged; futures have the same type as the actual result. Some frameworks allow futures to be passed to other processes. Such futures are called First class futures [2]. Replacing a future reference by the corresponding calculated value is called "future update". In this case additional mechanisms to update futures are required not only at the creator, but also on all processes that receive a future. First class futures offer greater flexibility in application design and can significantly improve concurrency both in object-oriented and procedural paradigms like workflows
First Class Futures: Specification and implementation of Update Strategies
ZIMEO E
2010-01-01
Abstract
Futures are language constructs that improve concurrency in a natural and transparent way. A future is a place holder for a result of a concurrent computation [5]. Once the computation is complete and a result (called future value) is available, the placeholder is replaced by the result. Access to an unresolved future results in the caller being blocked, until the result becomes available. Results are only awaited when they are really needed which helps in improving the parallelization. Futures may be created transparently or explicitly. For explicit creation, specific language constructs are necessary to create the futures and to fetch the result. Transparent futures, on the other hand, are managed by the underlying middleware and the program syntax remains unchanged; futures have the same type as the actual result. Some frameworks allow futures to be passed to other processes. Such futures are called First class futures [2]. Replacing a future reference by the corresponding calculated value is called "future update". In this case additional mechanisms to update futures are required not only at the creator, but also on all processes that receive a future. First class futures offer greater flexibility in application design and can significantly improve concurrency both in object-oriented and procedural paradigms like workflowsI documenti in IRIS sono protetti da copyright e tutti i diritti sono riservati, salvo diversa indicazione.