[cpp-threads] Asynchronous Function Proposal

[Boehm, Hans]

I think this is getting a lot closer to something we might want.  And I'm increasingly convinced that we need to have this design somewhat nailed down before we finalize some features already in the draft.  This discussion seems essential whether or not we decide to put this in C++0x.  I really don't think we want the current future in the standard if we can't use it here.

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.

- This is very different from Java thread pools, as it has to be, given the constraints.

- I don't have a clear intuition of how this could perform even with a simple tree-structured algorithm, like the ubiquitous fib example.  Assuming an implementation that creates a thread when the number of threads is below a certain threshold, I would expect that depending on exact timing, we actually get a bunch of threads executing high-level tasks (if newly created threads start running quickly), or most of the available threads are initially assigned to small tasks low in the tree (if the initial task gets to spawn all the threads before anybody else gets a shot at it).  My intuition is that the former would result in acceptable performance, where the latter would be awful.  But the only way I seem to be able to control this is by avoiding the may_be_called policy.  Maybe this isn't as bad as I think it might be.  I just don't know.  Doug Lea or Arch Robison probably understands this better.  Is a better implementation possible?

It seems to me that we're designing something here that's quite different from Cilk, TBB, or java.util.concurrent, which are perhaps the most established (?) systems in the area.  Given that we, and everyone ane everyone else in this area, seem to have a track record of getting into trouble even where there is clear existing practice that's supposedly "known to work", this still strikes me as quite risky, though perhaps unavoidable.

What would the overhead be of forking this into a small TR, so that we could more easily recover if we got this wrong?

Hans

> -----Original Message-----
> From: lawrence.crowl at gmail.com 
> [mailto:lawrence.crowl at gmail.com] On Behalf Of Lawrence Crowl
> Sent: Sunday, May 31, 2009 3:59 PM
> To: Bjarne Stroustrup; Boehm, Hans; C++ threads standardisation
> Subject: Asynchronous Function Proposal
> 
> Please take a look at the attacked draft proposal for the 
> async function.  Comments are encouraged.
> 
> --
> Lawrence Crowl
>