Futures and Promises - Relations Between The Expressiveness of Different Forms of Future

Relations Between The Expressiveness of Different Forms of Future

Eager thread-specific futures can be straightforwardly implemented in terms of non-thread-specific futures, by creating a thread to calculate the value at the same time as creating the future. In this case it is desirable to return a read-only view to the client, so that only the newly created thread is able to resolve this future.

To implement implicit lazy thread-specific futures (as provided by Alice ML, for example) in terms in non-thread-specific futures, needs a mechanism to determine when the future's value is first needed (for example, the WaitNeeded construct in Oz). If all values are objects, then the ability to implement transparent forwarding objects is sufficient, since the first message sent to the forwarder indicates that the future's value is needed.

Non-thread-specific futures can be implemented in terms of thread-specific futures, assuming that the system supports message passing, by having the resolving thread send a message to the future's own thread. However, this could be argued to be unnecessary complexity: in programming languages based on threads, the most expressive approach appears to be to provide a combination of non-thread-specific futures, read-only views, and either a 'WaitNeeded' construct or support for transparent forwarding.