[cpp-threads] Asynchronous Function Proposal

[Robison, Arch]

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

I'd be curious to see where the reentrancy with the "t must complete..." restriction introduces deadlock.  I'm painfully aware of the problem if there is no such restriction.  The "t must complete..." restriction is intended to be a safe generalization of the "inline t if it's a child" notion.

- Arch Robison