[cpp-threads] Asynchronous Function Proposal

[Herb Sutter]

Anthony wrote:
> >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.

Anthony is correct. Requiring a new thread every time would be a serious flaw.

> 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.

I don't think we can or should rely on future optimizations. Besides, it would kill async()'s usefulness on work-stealing and thread-pool implementations today.

> 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.

I can share some examples where this kind of reentrancy would inject deadlocks or data corruption, if the tasks acquire a mutex that is non-reentrant or reentrant, respectively.

It's pretty safe to inline task t if it's a child of this task (the primary motivator for work stealing) and possibly if it's a sibling also created by this same thread.

Herb