Re: [boost] Futures

Subject: Re: [boost] Futures
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2015-01-05 09:47:12

On Sunday, January 04, 2015 17:03:48 Vicente J. Botet Escriba wrote:
> Le 04/01/15 11:25, Thomas Heller a écrit :
> > On Sunday, January 04, 2015 06:52:41 Niall Douglas wrote:
> >> On 3 Jan 2015 at 7:15, Hartmut Kaiser wrote:
> >>> First of all, I fully support Thomas here. Futures (and the extensions
> >>> proposed in the 'Concurrency TS') are a wonderful concept allowing
> >>> asynchronous computation. Those go beyond 'classical' futures, which
> >>> just
> >>> represent a result which has not computed yet. These futures allow for
> >>> continuation style coding as you can attach continuations and compose
> >>> new
> >>> futures based on logical operations on others.
> >> 
> >> They are also severely limited and limiting:
> >> 
> >> 1. They tie your code into "future islands" which are fundamentally
> >> incommensurate with all code which doesn't use the same future as
> >> your code. Try mixing code using boost::future and std::future for
> >> example, it's a nightmare of too easy to be racy and unmaintainable
> >> mess code. If Compute provided a boost::compute::future, it would yet
> >> another new future island, and I'm not sure that's wise design.
> > 
> > I absolutely agree. "future islands" are a big problem which need a
> > solution very soon. To some extent the shared state as described in the
> > standard could be the interface to be used by the different islands. What
> > we miss here is a properly defined interface etc.. I probably didn't make
> > that clear enough in my initial mail, but i think this unifying future
> > interface should be the way forward so that different domains can use
> > this to implement their islands.
> Hi Thomas.
> Can you share your ideas of what this unifying future interface could
> be? are you thinking on a dynamic or parametric (static) polymorphism?
> What is the minimal interface of a Future that allows to build higher
> and efficient abstraction on top of it?
> 
> > FWIW, we already have that in HPX and we are currently integrating OpenCL
> > events within our "future island", this works exceptionally well.
> 
> I've no doubt you have reached a good integration on your island. The
> main issue is how to be able to add new 'Futures' without been forced to
> modify existing code or making use of internals of a specific island and
> take advantage of other higher level mechanism based on 'Generic Futures'.

Let's try it.
Let's try to summarize the landscape of what we currently have and formulate a 
list of requirements. There are various C++ standard proposal and a TS dealing 
with that issue, The C++ standard I am referring to in the following is the 
current working draft N4296[1]. What we currently see is a fragmentation of 
the landscape into different future islands. So, what we have in the standard 
is the basic specification of a shared state which is used as a communication 
channel between an asynchronous return object and an asynchronous provider 
(30.6.4). The standard furthermore defines 3 providers (promise, packaged_task 
and async), and two return objects (future and shared_future). What's 
particularly interesting here is that 30.6.4 doesn't speak about threads or 
synchronization between threads. For me, the reason why we have the different 
future islands is because of the fact that the shared state doesn't have a 
specified API and customization points. If that would be the case, the async 
return objects can hook onto that API to generate a unified future and 
shared_future while the providers have every freedom to generate asynchronous 
results.
The only open question is how this shared_state should look like.
A specific future island might have problems using the already existing 
providers like promise, packaged_task and async because they don't want to use 
the stdlib implementation provided thread and thread synchronization 
primitives for one reason or another. This might be because they are 
unsuitable (HPX and Boost.Fiber) or because they adapt a 3rd party library 
like OpenCL which provide their own shared state implement (an OpenCL event is 
kinda like a shared state!).

The big question now is: How could such a shared_state API look like? To be 
honest, I have no idea. What i believe though is that the reference counting 
specification should be absolutely required due to various reasons like 
shared_future or keeping the communication channel alive in the event of an 
asynchronous task.

The providers like async, when_XXX and future<T>::then should be considered in 
this discussion as well because it is unclear which type of shared_state they 
should create. This can be solved via executors. Yet, I am not sure if the 
current state of the executor proposal is able to cope with my ideas here.

Please don't hesitate to complete the list or point to obvious mistakes.
Please also note that some of things stated above are kept vague because I 
don't have a solution to it or I think they require further discussion.

[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf
> 
> Best,
> Vicente
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost