[cpp-threads] Asynchronous Execution Issues

[Herb Sutter]

Just to chime in briefly (sorry, have no time right now to dive deep):

> two async()s: the one that guaranteed to run on a separate thread
> (so that you could imagine the two tasks communicating) and the one that
> did not offer that guarantee (for the simplest tasks, potentially
> executed on the launching tasks if it has nothing better to do). 

The above is exactly that we need, IMO. That is the key distinction that affects the program semantics: Am I guaranteed to run on another thread, or not?

> I'd not like to see the former split further into two (new thread vs.
> potentially re-cycled thread) and I can't see how that could be done
> without exposing the underlying thread/thread-pool machinery (which we
> decided not to include in C++0x).

I don't see how "new vs. recycled thread" affects the program semantics. I saw what Lawrence wrote, and I don't see it -- if my code is guaranteed to run on a different thread than the original one launching the work, it makes no difference to me whether that other thread is brand new or ran something before because I can't rely on it happening (and don't see any need to rely on it), even if I could detect _whether_ it happened in code because thread locals weren't destroyed.


> The purpose of async() - as for future - is to allow people to use
> concurrency without having to deal directly with underlying systems
> facilities, such as task and locks. Instead, futures together with
> async() allow the user to think of asynchronously executed tasks
> returning values through futures.

Yes. And the only semantic distinction that matters (to me) is whether or not I'm guaranteed to run it on a different thread than this one that's launching the work.

Herb