[cpp-threads] Asynchronous Function Proposal

[Lawrence Crowl]

On 6/1/09, Herb Sutter <hsutter at microsoft.com> wrote:
> Peter wrote:
> > I do not agree with your choice of (only) providing a policy that
> > executes on get(), neither do I agree with the choice to remove
> > wait, has_value and has_exception because of it. Furthermore,
> > the name "must_be_called" does not make sense for this policy,
> > because it in fact never calls the function unless there is a
> > get() call.
> >
> > The sensible policies are (in my opinion):
> >
> > - at implementation's discretion (default)
>
> Yes, meaning "might execute synchronously on this thread."
>
> > - launch in a thread pool
> > - launch in a separate thread
>
> I don't see the need to distinguish these. The only thing the
> user cares about is "guaranteed not to execute synchronously on
> this thread."

These are distinguished under the issues mentioned in N2880.
In particular, using thread pools requires exposing the pool to
the user.  The ground rules for the async function is "no pools".

> I was about to say I'm not opposed to distinguished these, but
> then I remembered we don't have thread pools so now I am opposed
> because allowing that one will stir controversy. ;-)
>
> > - execute immediately (for generic contexts)
>
> Yes, but that is needed (only?) for testing and would be routinely
> provided as a QoI extension. No harm in providing it though.
>
> > - defer until wait() is called (not get)
>
> I'm not opposed to including something like this, but I have seen
> no experience with it or need for something finer-grained than
> "execute immediately." Is there?

For serial execution, I don't think it is a granularity issue.
The choice seems to be (1) do the call immediately, and (2) do the
call later.

The real issue is that you need a policy that says "do sequentially"
to avoid the overhead or misappropriation of resources that comes
with launching a thread.  This ability to retract parallelism
is important, particularly during the tuning phase of program
development.

> > I think that an enum parameter may be better as a policy because
> > it would allow the choice to be made at runtime.
>
> Yes, and it's simpler.
>
> So I would (strongly) suggest having only:
>
>  enum AsyncPolicy {
>    /* default, might run synchronously or asynchronously */ ,
>    /* guaranteed to run asynchronously on another thread */ ,
>    /* guaranteed to run synchronously on this thread */
>  };
>
> That boils it down to the two important and mutually exclusive
> cases the user cares about and an "implementation-defined" default,
> which is complete and readily explainable. Is there a need for
> something more?

But those policies are what I proposed, where "this thread" is
defined as the thread that calls get().

-- 
Lawrence Crowl