[cpp-threads] Asynchronous Function Proposal

[Robison, Arch]

>-----Original Message-----
>From: cpp-threads-bounces at decadentplace.org.uk [mailto:cpp-threads-
>bounces at decadentplace.org.uk] On Behalf Of Anthony Williams
...
>Boehm, Hans wrote:
...
>> It's unclear to me whether that means that exceptions should
>> sometimes become visible at the point of async creation or not.  It
>> may be that space-based throttling is rare enough that we can afford
>> any extra overhead needed to defer the exception, though that's
>> probably surprising in some cases.  Having to handle exception in two
>> places also seems unfortunate.
>
>I strongly feel that if the results of running the async task should be
>stored in the returned future *whenever* that task is run (including if
>it is run directly as part of the async call and is complete before the
>call to async returns). This includes any exceptions thrown. The only
>reason the async call itself should throw an exception is because the
>call itself failed (too many tasks, too many threads, not enough memory,
>whatever....) rather than anything to do with the behaviour of the task
>being run potentially asynchronously.

I'm also for deferring the exception, even if the task runs immediately.

>> Even if exceptions are handled only at the request point, we need to
>> explicitly allow running the task earlier, since that's visible by
>> other means.
>
>Yes, if we intend to allow it (and I think we should) then it needs to
>be specified as permitted.
>
>> I would still favor sticking with Lawrence's design that avoids
>> (visibly) reusing threads for multiple tasks.
>
>I don't think we should specify whether or not the threads are reused.
>If we say threads *may* be reused, then the user cannot rely on anything
>(they may get a fresh thread or be the last task on a thread anyway) and
>it gives implementors greatest freedom.
>
>If we don't allow thread reuse then you force implementations to spawn
>threads repeatedly. You also disallow task stealing, since effectively
>the only point of such a mechanism is that you already have a thread
>running that can steal the work.

If the proposal is adopted, I would think that OS vendors would eventually provide the hooks to make implementations run fast; e.g. provide a way to quickly reincarnate a hardware thread as a different software thread.
 
The issue of recycling threads is a difficult one and has been vexing for TBB.  Always running on a new thread minimizes surprises, but is expensive.  At the other extreme, an implementation that gives implementers maximum freedom is to allow a thread waiting on handle.get() to steal another task.  This is the choice we made in TBB.  Allowing it can improve performance, but can also cause deadlock unless the user observes certain restrictions.

There's an intermediate choice where a thread waiting on handle.get() is allowed to steal another task t only if it can prove that t must complete for handle.get() to complete.  We've not yet analyzed how that rule impacts performance in TBB.

As long as the policy is parameterized, implementers and users can experiment to find out what is viable in practice.  So I think the proposal in hand (with the space throttling adjustment) is a good step in evolving parallel support in C++.

- Arch Robison