[cpp-threads] Asynchronous Function Proposal

[Boehm, Hans]

[Adding Pablo, Arch, and Doug:  This is a continuing discussion of Lawrence Crowl's proposal for a simple C++ facility to support asynchronous function call execution.  Reattaching Lawrence's proposal for newcomers.]

> -----Original Message-----
> From: Herb Sutter
> 
> > But I'm still worried about whether we have enough of the details 
> > right here that this facility will actually be usable.  I 
> don't have 
> > the necessary experience that I feel I can evaluate a 
> design.  As far 
> > as I can tell:
> > 
> > - I believe this doesn't support a Cilk-like (or TBB-like?) 
> > implementation.  I believe Cilk effectively allows colder 
> call frames 
> > to be stolen by another thread, for example.
> [...]
> 
> A primary reason I've been advocating an "async()" facility, 
> besides as a way to make async calls easy, was specifically 
> to make sure that an async() with a default "could execute on 
> this or another thread" policy could be implemented to run on 
> a work stealing implementation, such as Cilk, TBB, or our own 
> TPL/PPL/ConcRT. I haven't seen anything that would prevent 
> that -- all you need to say is exactly "could execute on this 
> or another thread" and IIUC that's all we need.
I'm not an expert on this stuff.  (Copying Pablo in case he can help and hasn't seen this.) But my understanding is that when Cilk is about to execute a spawned task, it pushes a work item on the task queue that represents the parents' continuation.  That pushed item may get stolen by another worker thread.  Thus the parent thread may appear to have migrated between threads.  My vague intuition is that this is necessary if you want to both:

- Efficiently execute child tasks on the parent thread in the common case, and
- Be reasonably sure that when you steal a task, you're likely something reasonably large, from closer to the root of the tree.

If I understand this correctly, this doesn't mesh particularly well with a bunch of other thread facilities in the current draft, e.g. thread-local variables.  (There are more details on Cilk in their PLDI 98 paper http://supertech.csail.mit.edu/papers/cilk5.pdf .)

TBBs tasks are more complicated to use, since they don't rely on language support.  They may avoid this kind of issue; I'm not sure. (Copying Arch in case he can help.)

My impression is that for both Cilk and TBB, interactions with other C++0x thread facilities haven't really been worked out.  (Not to surprising, since we're having enough problems with interactions between C++0x facilities, not to mention weird interactions within older systems we're building on.)

Hans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.decadentplace.org.uk/pipermail/cpp-threads/attachments/20090603/57faf5f1/attachment-0001.html>