[cpp-threads] Asynchronous Function Proposal

[Lawrence Crowl]

On 6/13/09, Herb Sutter <hsutter at microsoft.com> wrote:
> > > I don't understand that last part. Of course there's a single
> > > call site; you always start a function (and now async task)
> > > in one place. But of course there can be multiple consumers of
> > > the result of the computation; you often use the result (and now
> > > future<result>) in multiple places.
> >
> > To use the result in multiple places in sequential code, you must
> > store the function result in a variable and then copy it around.  The
> > situation is no different with a single-invocation async_future::get.
>
>
> No, I'm sorry but that's unreasonable to assume/require/enforce. This
> fails to distinguish between spawning (or sending a message to) other
> code that needs to receive the result immediately vs. that needs to use
> the result eventually. Sometimes the former is fine, but often it's not
> when you don't want to be forced to collapse concurrency.
>
> In async code, the corresponding sentence is usually found by doing
> s/result/async result/, in this case:
>
>   To use the aync result in multiple places, you must store
>   the async result in an async variable and then copy it around.
>
> i.e., as a shared_future. There's no problem with doing this if you use
> packaged_task/unique_future directly, which is what async() is supposed
> to wrap/hide.

The model for this feature, as I understand it, is to provide a means
for people with a sequential program to easily upgrade it to exploit a
small number of cores.  It is not to maximize concurrency or efficiency,
for which we need the more advanced facilities that we agreed to defer
until after C++0x.

The easiest way to do the upgrade is to initiate selected function
evaluations early, so that their results are available when need in the
mainline sequential code.  I believe the interface supports that use
at the least risk to develpment and implementation.

If there is a requirement for additional use cases, I would like those
requirements and use cases stated more explicitly.  In particular,
saying how we might have use for more flexible primitives may lead to
allegations of feature creep without use cases that the committee
agrees are valuable.

> You do not want to force people to lose concurrency. Forcing that is a
> non-starter. The proposal needs to be changed to return unique_future
> anyway for several reasons, but this is one of them.

They aren't loosing concurrency, they are gaining it.  They might not
gain as much as more sophisticated approaches, but I didn't think we
were going there.

> I haven't read the revision yet, but the first serious problem is that
> it didn't switch to unique_future.

Switching to unique_future can be done relatively easily at Frankfurt.
Creating an async_future proposal at Frankfurt would not be easy.  So,
in the interests of leaving our options open, I would much prefer to
keep async_future in the proposal.  I addressed the choice in the paper,
and I'll happily expand that section to meet your concerns.

-- 
Lawrence Crowl