[cpp-threads] Asynchronous Function Proposal

Herb Sutter hsutter at microsoft.com
Thu Jun 18 01:09:46 BST 2009


Short answer to one part:

> > Anything that uses a shared_future is a use case. As I mentioned
> > recently, the key is that we want to pass a value somewhere, and
> > sometimes the target needs the value immediately and sometimes
> > it needs it eventually. From my note on 6/3:
> 
> No, I don't believe "anything that can use shared_future" is a use
> case, in part because of the issues above.  Show me code that solves
> a problem.  I agree that the mechanisms can be used in arbitrary
> ways, but not all of them make sense.

Clearly I don't understand our disconnect. Sorry, I'll keep trying.

Maybe the simplest example is something like this:

  // threads 1..N that all eventually inspect an intermediate result

  void thread_main( shared_future<int> intermediateResult ) {
    ...
    ... possibly lots of work that can and should run in parallel
    ...

    result = intermediateResult.get();

    ... use result
    ... and do some more work
  }

The threads are independent and so naturally will block for the intermediate result at different times, depending how long the first chunk of each one's work takes. That work should run in parallel. So we use a shared_future<Something>. Yes, there are other designs, but if someone objected saying "why not use a global unique_future," but clearly we'd respond the same way as if someone similarly wanted to avoid using a shared_ptr by substituting a global unique_ptr.

The future can be provided by, and later set from, any old thread(s). Why not by/from an async()?

If that doesn't answer your question, can you help me understand what is missing from the above argument for why async() should return something convertible to shared_future? It seems obvious to me, but maybe I could be missing some implicit assumption I'm making and not communicating...?

Herb





More information about the cpp-threads mailing list