CppCon 2015: Arthur O'Dwyer “Futures from Scratch...'

—
Futures from Scratch: A Guided Tour of Concurrency in C++14 and Beyond
--
—
The contents of header are probably still a bit mysterious to most people. Sure, we know that setting the value of a promise causes the corresponding future to resolve; but how does that happen behind the scenes in a way that allows us to move futures around? How are we going to implement the new features in the Concurrency TS, such as .then() and .when_all()? How (if at all) do futures interact with std::thread, std::async, and "executors"?

We'll present an extremely simplified implementation of futures and shared_futures, without the template metaprogramming that comes along with future and future and so on, but showing all the pointers and synchronization primitives.
—
Arthur O'Dwyer worked for many years at Green Hills Software, making the world's most optimizing C and C++ compilers. Now he works at Mixpanel in San Francisco, where he organizes a monthly C++ meetup.
—

*-----*
*-----*

[MagnificentImbecil]

IMO: Great talk -- I have been able to understand more things and more clearly. Plus very interesting personal contributions presented in the last 20 minutes.

At 50:00:

For someone writing aplication code:

Maybe it is not possible to add a member-function unlock to std::shared_ptr,

but it might be possible to add a non-member function (yes, even if not in namespace std, thus not giving the benefits of Koenig Look-up),

so instead of "wptr = sptr.unlock ()"

the user can write "wptr = my_namespace::unlock (ptr)"

and it might still fit on a slide.

[scottwillis]

One thing bothers me. There was hand-waving and "why would anyone want to do that" around being able to find out the internal state of the structures. My initial guess is that this is based around the original author of the library code, who is:
- Dealing with a single, small piece of demonstration code
- Intimately familiar with the library code
and thus immediately knows what went wrong

Imagine, if you will, a developer working in a large team, debugging a complex system with an intermittent problem. If they are really lucky, this is during development (vs. in the field) and the original developers are still around.

Examples:
1. Five expensive computations are launched. The function that launched them, and waits for a join to complete, never comes back. Which one(s)?
2. For a large system during operation, over time, 100, 000 expensive computations are launched. Fifteen do not complete, at least not in a timely fashion.

I would like to see more attention given to the needs of developers working in teams on large projects. Status interfaces, please!

[MagnificentImbecil]

At 38:00:

Regarding application on an empty set of futures:

when_all returns true and when_any returns true and "That is a little bit weird. [...]".

It would have really been weird if, for the same set of futures, when_all had returned true (i.e. the stronger condition had been fulfilled) and when_any had returned false (i.e. the weaker condition had not been fulfilled).