QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunYes, futi.get() are blocking till the i-th thread finished. First launch all threads with std::future, then futi.get() all threads, when the first thread finished, the first get will stop blocking and at that time the other 3 threads should be ready too.Indeed. In this case since there is no shared data we can define the rendezvous point after firing up all futures. Now I get the same results as expected, both for C+11 and PPL.Pff! Indeed, if you have shared data and dependencies between threads like "thread 2 is waiting for thread 1s result" then this won't work! The order of gets will then be important.I must say I like simple threads better than future/get, but maybe it's "what the farmer doesn't know he doesn't eat"In the beginning I also found future non-intuitive until I use a task graph to visualize it. I think one can write the sequential version and then look for potential parallelism. It is almost 1:1 mapping to code and that is cool IMO. Sure beats ad-hoc experimentation.I think that can be done for any problem of any size.BTW the answer from the code is 42.
Last edited by Cuchulainn
on August 27th, 2015, 10:00 pm, edited 1 time in total.