I’m about two weeks late posting this, but two more C++ and Beyond 2012 videos are now available online.
The first is my concurrency talk:
C++ and Beyond 2012: C++ Concurrency (Herb Sutter)
I’ve spoken and written on these topics before. Here’s what’s different about this talk:
- Brand new: This material goes beyond what I’ve written and taught about before in my Effective Concurrency articles and courses.
- Cutting-edge current: It covers the best-practices state of the art techniques and shipping tools, and what parts of that are standardized in C++11 already (the answer to that one may surprise you!) and what’s en route to near-term standardization and why, with coverage of the latest discussions.
- Blocking vs. non-blocking: What’s the difference between blocking and non-blocking styles, why on earth would you care, which kinds does C++11 support, and how are we looking at rounding it out in C++1y?
The answers all matter to you – even the ones not yet in the C++ standard – because they are real, available in shipping products, and affect how you design your software today.
The second is one of the panels:
C++ and Beyond 2012: Panel – Convincing your Colleagues
From C++ and Beyond 2012, Andrei, Herb and Scott present Convincing Your Colleagues – an interactive panel.
Abstract:
You can’t do a better job if you don’t change what you’re doing, but change is hard. It’s especially hard when what needs to change is your colleagues’ approach to software development. Moving your team forward often requires persuading your peers to change their behavior, sometimes to do something they’re not doing, other times to stop doing something they’ve become accustomed to. Whether the issue is to embrace or avoid C++ language features, to adopt new development tools or abandon old ones, to increase use of or scale back on overuse of design patterns, to adhere to coding standards, or any of the plethora of other matters that affect software creation, moving things forward typically requires getting your colleagues to buy into the change you’re proposing. But how can you do that?
In this panel session, Andrei, Herb, and Scott share how they go about convincing their colleagues to change and take questions from the audience.
Truth be told, the panel ranged widely and probably most of the time was on other topics!
I hope you find them useful.
Sutter’s Mill 
Some months ago this talk inspired me to write a blog note, “Pike & Sutter: Concurrency vs. Concurrency”, see http://www.teigfam.net/oyvind/home/technology/072-pike-sutter-concurrency-vs-concurrency
(Herb Sutter, you have already posted comments in my blog note, so you are aware of it. But I would of course like to attract new readers!-) I have written a naïve follow-up called “Block play for blockers”. I am now reading myself up with a goal to try do a note on event-loop concurrency vs. CSP-type concurrency/parallelism with channels.)
Oyvind Teig, Trondheim, Norway
The talk was great.
Is a thread per concurrent object the right pattern?
I thought we were supposed to be moving away from directly dealing with threads and towards something more like submitting tasks to run on a thread pool which runs as many threads as is optimal on the executing system and no more.
@Fernando: I just remembered the other reason why .then(x).then(y) is useful — yes you could write it as .then(x+y) but that burns/occupies a thread, whereas .then(x).then(y) does not. I’ll go back and update the previous note to include that.
@Herb: The .then() template you show would compile as you say, but does not appear like it would work as it’s relying on shared futures by the looks of it, I have a SO question on it here http://stackoverflow.com/questions/14200678/c11-async-continuations-or-attempt-at-then-semantics If you have other ideas in this regard them brilliant as .then or then() would be a great pattern till the standard provides these implementations (never mind await which would really alter the landscape of many codebases)
On the wrapper class there is a nice gotcha for non msvc compilers in this SO question as well http://stackoverflow.com/questions/14188535/clang-access-modifier-order-and-decltype Looks like msvc is non-conformant here as well as with the future blocking discussed earlier.
I think it would be good to have working examples of some of the code in a couple of compilers as msvc seems to not be to concerned with template errors (missing typenames etc.) at compile time, so a ‘compiling’ template example, particularly one not instantiated is limited in value (in some compilers).
It would be extremely helpful if you had non conforming implementations of std:: clearly available in a public forum or web page and perhaps even a warning that can be switched of to let devs know they were implementing non cross platform behaviour or similar as this is a key part of the standard as far as I believe (cross platform compliance).
Great talk (as ever) though and mixed with the const/mutable it’s fantastic to get people thinking c++11 proper and not just using auto and lambdas, there is a lot more and this is great. Cheers again.
Gotta love the English language! And I agree with you, that the bug is in the standard.
@Fernando: You asked why not just write w.then(x+y+z) instead of w.then(x).then(y).then(z). Two reasons: 1. Writing w.then(x+y+z) burns/occupies a thread while waiting for y and z, while w.then(x).then(y).then(z) does not. 2. An important key is composability: The different .then() calls may be in different code, such as one function doing w.then(x) and returning the future, the separately authored caller tacking on .then(y) and storing it on the heap for multiple threads to observe, and then a helper thread authored by still someone else tacking on .then(z).
@Adam H: Right, VS 2012 is knowingly (temporarily) non-conforming on the ~future blocking issue in part because we knew this question is being actively reviewed in the committee and we feel the status quo is harmful to our customers. Of course, if the committee’s decision is to stay with the C++11 rules we’ll change our implementation to conform and have to do more to educate customers about the issue.
If the view that this should be fixed prevails in the committee, we’ll look like geniuses for getting it “right” sooner, otherwise we’ll conform and look like doofuses for shipping with another bug we had to go back and fix.
(We don’t do this often! Usually the right thing to do is just conform to the standard, perceived bugs and all. But this bug is bad and under discussion at the last two SG1 meetings…)
Thanks for making these available, Herb! I enjoyed both talks very much. Always interesting listening your words (and of course Andrei’s and Scott’s :D)
Hi, and thanks for making C++ an even more awesome language, and thanks a lot for your work in enabling further improvements!
Sorry for this OT question, but I did not know where else to post it…
In September 2012 you posted a paper discussing the problems in the present standard, with a blocking ~future(). In my experiments I have found that it does no block! (VS 2012 – update 1)
Has the standard already been revised? Nice, but I would’ve thought that the standard was already carved into stone? Shed some light, anyone?
For those of you who wonder what on Earth I am talking about, here’s what:
void DoWork( const std::wstring& s, unsigned int wait )
{
std::wcout << s << L" Begin:" << std::endl;
std::this_thread::sleep_for( std::chrono::milliseconds ( wait ) );
std::wcout << s << L" Done." << std::endl;
}
void SimpleAsyncTest()
{
// Test Herb Sutter’s blocking ~future
// http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3451.pdf
std::async( std::launch::async, [](){ DoWork( L”Slow Work”, 400 ); } );
std::async( std::launch::async, [](){ DoWork( L”Fast Work”, 200 ); } );
}
// “Slow work” completes last, as intuitively expected, but contrary to paper above
The concurrency talks are great! But there is one single unanswered question in the air:
What about race-conditions?
In C++ there is no compile-time help to notify when I’m using a non-thread-safe function. This proliferation of new concurrency abstractions increases the probability of accidentally calling such a function. I have no idea how this works in C++/CX, but seemingly nobody is giving a thought about race-conditions in any of these talks.
Am I missing something? Is concurrency now simple and the problem with race conditions has been solved in the meantime? :D
(Re-posting the channel9 question here for context)
@HerbSutter: Thanks for sharing another great presentation.
I have one question that has been bothering me since the first time I read your enthusiasm about “future.then”:
i.e. consider async(task1preparation)
.then(task2continuation)
.then(task3cleanup)
.then(task4notifyUI)
isn’t that the same as async([]() -> void {task1preparation(); task2continuation(); task3cleanup(); task4notifyUI();}); ?
What would be the benefit of using future.then as proposed?
I’d see more benefit if instead of a chain of actions, I could get a tree than depending on the result of the first task (or exception) and could have custom continuations. Also It would be useful (not sure if that is already proposed) to specify that a given continuation task should run in the current thread or in a specific thread (i.e. UI thread).
Thanks in advance for your clarification
Fernando