C++ and Beyond 2012: Herb Sutter - C++ Concurrency

Play C++ and Beyond 2012: Herb Sutter - C++ Concurrency
Sign in to queue


Herb Sutter presents C++ Concurrency. This was filmed at C++ and Beyond 2012.

Get Herb's slides for this session.

Herb says:

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.



Download this episode

The Discussion

  • User profile image

    am I right that this concludes the lectures from CppAB?
    Either way thanx for sharing them I liked them a lot (less than STL's videos, but then again do I like anything more than STL's videos ? :) )
    for people wanting more of Andrei they can find link for his 3 optimization tips talk on isocpp.org.

  • User profile image
    @Ivan: There are 2 more videos from this series. They will air sometime in the next two weeks.
  • User profile image


    Are Andrei's two talks on "Writing Fast Code" going to be uploaded?

    I hope so!


  • User profile image

    Good stuff. I'll second the call for Andrei's talks! Loving all this C++ content, almost makes up for being banished to the native code desert for the past decade plus.

  • User profile image

    @Alastair: Nope.


  • User profile image

    Very nice. Thanks for providing these!

    Could the slides be made available for download?  Cool

  • User profile image

    I watched the whole thing.. I kinda missed
    "Task and data parallelism" and "Work stealing" part, I'm also under impression that the talk was planned to be longer?^^

  • User profile image

    @Charles, tnx for the A.
    @Alastair: read my first comment, it might be helpful. :D

  • User profile image

    Really!? I love Herb Sutter's talk very much! and there is "Task and data parallelism", "Work stealing" part? Can Channel 9 help to upload them?

  • User profile image

    I am not able to download the high quality wmv (2.9G) completely. The connection is getting closed somewhere around 1.7G. Can you look into it?

  • User profile image

    Concurrent<T> looks very similar to the EventLoopScheduler in the Reactive Extension library (Rx). Nice feature to have the Thread.Join in the destruction. Also nice to get the result back in a future, however .NET would just use Tasks<T> for this. Scheduling is a slightly different problem space, better suited for the fire and forget problem like the logging example.

    Good session as usual


    .NET dev,  but interested in what ever Herb says Smiley

  • User profile image

    boost::asio cough cough...

    wait() is stupid.

  • User profile image

    i mean blocking get(), that's stupid.

  • User profile image

    Re task and data parallelism: We announce the "preliminary" talk descriptions months before the actual C&B event, and we make changes as we firm up the content. For C&B 2012 I had too much material for other talks and so the parallelism part got cut. Charles grabbed the original draft description and I've asked him to update the description -- basically remove the 'parallelism' bullet.

    That said, there's a lot of interesting stuff to be said about C++ parallelism too, so I may well cover that parallelism topic at C&B 2013 (unless it gets preempted by something even more current and cool). The dates for that event have been announced for December 8-11, and the location will likely be announced soon -- just follow cppandbeyond.com if you're interested.

  • User profile image

    I enjoyed the talk, but of course, it doesn't tell the whole picture.

    As Herb mentioned, there are basically two ways to deal with shared resources: put a lock around it (mutex), or give the resource "thread affinity" via something like a message queue.  Neither one guarantees responsiveness, and if you want your program to clean up gracefully, both will have a "wait" at some point.

    Basically, message queues don't guarantee responsiveness because one item in the queue could take a long time, and prevent the other items from being performed in a timely manner.  In some applications, this shows up as a pause, followed by a rapid catch up as all the queued up events fire at once.  This can be mitigated by splitting up your resources in a more fine grained manner, and putting the "slow" resources on their own threads.  You can't just throw a thread pool at the problem though, as then you need to reintroduce mutexes.

    As for the graceful cleanup, leaving threads running after main() exits is usually a bad idea.  You can also run into problems if your application dynamically loads and unloads shared libraries, and you leave threads running that execute code in the unloaded library.  Both of these cases are handled poorly by Herb's "stop message" implementation, at least if any of the messages are slow.  You really want to be able to eject all existing items in the queue, and preferably signal the currently running item to stop.  Not all apps need to clean up gracefully though.

  • User profile image
    Jason Toffaletti

    I wrote something very similar to monitor<T> 7 months ago, but missed labeling the members as mutable and I didn't allow a return type.


    I need concurrent_queue today. The coolest thing I've seen done with C++11 uses many of the techniques discussed in this talk to implement Actors for C++ http://libcppa.blogspot.com/

  • User profile image

    @Herb: during this talk you mentioned that there were/are problems with string COW? Could you tell me where I can read more about that topic, please?

    Great and interesting talk!

  • User profile image

    Great talk, many thanks!


    Would it be possible to get an uploaded version of the slides?

  • User profile image
  • User profile image

    @Ivan: New around here but loving it... Could you point me to whatever these STL videos are that you so highly recommend? If you deem it to be even better than Herb's talks I'm super curious!

  • User profile image

    Very nice. Thanks for providing these!

  • User profile image

    @FeignMan: STL's videos can all be found here -> https://channel9.msdn.com/Tags/stephan-t-Lavavej


  • User profile image

    This session is really cool, many thanks.
    Anyway I am a little bit confused about monitor<T>.

    I could understand why std::mutex is mutable (I mean thread safe under C++11).
    But why T is mutable?

    The all public interfaces of std::mutex would provide thread safe but what about T?
    I guess only const member functions would provide thread safe.

    Should mutable be a qualifier for that instance of std:mutex or the std:mutex class itself (C++1y)?
    Could mutable be a qualifier for a member function such as const (C++1y)?

    Which one is better?
    1. template <typename F> auto operator()(F f) const
    2. template <typename F> auto operator()(F f) mutable

    If const member T functions would provide thread safe, why bother to operate under std::lock_guard<mutex>?
    I know monitor<T> would be easier to provide a general solution under a thread safe way.

    But I might use a dangerous way like below for some critical cases (it might be very few)
    template <class T> class monitor : public T {
        mutable std::mutex m;
        monitor(T t_ = T{}) : T(t_) {}

        template <typename F> auto operator()(F f) ...

    I might call some const member T functions directly for precondition checking whether I need to go for operator() under critical cases.

  • User profile image


    Very interesting talk.

    One question:

    Looking at monitor<ostream&> sync_count{cout}

    This results in a compilation error on my compiler (Xcode V4.5.2 using Apple LLVM 4.1)

    mutable T t;
    'mutable' cannot be applied to references

    I *think* the error is correct. Or am I missing something?


  • User profile image
    Michal Mocny

    @Ben_Craig: Yes, your points about resources with thread affinity possibly blocking due to long running tasks was exactly what I was thinking throughout the talk! Also, a simple case that simply leads to less parallelism: the concurrent<..>(cout) provided in the sliders -- imagine writing your entire application using having many chunks of work being provided print tasks -- that would be a bad pattern). Basically you should make the tasks as lightweight as is possible/applicable, but that may not be possible without access to the shared resource, etc..

    The points in this talk are still fantastic, and it is another tool in our belt, but I wish a little bit more time was spent discussing those tradeoffs.

    Also, regarding your specific use of lambda wrapper all over the place, it seemed there were very many copies being made. What about move only types? Perhaps that is a generalized question, why dont lambda capture by move? by perfect forward?

  • User profile image
    Fernando M

    @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)

    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


  • User profile image

    The syntax used for monitor and concurrent is bad:( Repeating the object name(and type in C++11) is just wrong..

    Suggest adding some syntax(language supported) to clean it up

  • User profile image

    Just noticed Fernando posted the same question here as on my blog... pasting the answer here too:

    @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).

  • User profile image

    Thanks for making the slides available! This is a great talk/presentation.

    @Charles I'm keen to see more Concurrency. Will there be more on talks that include using Concurrency Runtime and other libraries available in Visual Studio? I see some other videos but they are 3-5 years old, are they still relevant now that VS2012 is out? Which ones are recommended?


  • User profile image


    How could be concurrent_queue<T>::push method non-blocking if it passes some data from the caller thread to the worker thread?

    I believe the implementation of this method is also based on some lock/free functionality to enqueue the job safely. For example, if many callers invoke concurrent_queue<T>::push method concurrently, each caller might be blocked by concurrent_queue<T> class internal synchronization mechanism, for instance, by a mutex. Otherwise, if push method has no internal synchronization, we cannot say that it is concurrently-safe.

  • User profile image
    Brian Cole


    We've debated this talk quite a bit around our office. It seems what is confusing people is when is it proper to mark a method "const"? For example, operator() in the concurrent<T> class is marked "const" in order to say that it can be safely called from multiple threads:

    template<typename F> void operator()( F f ) const { q.push([=]{ f(t); }); }

    However, under this reasoning, you can claim that concurrent_queue::push should really be a const method as well. If concurrent_queue::push was const, there would be no need for concurrent_queue to be marked as mutable. Hence, the confusion.

    Perhaps a more pedantic and frightening example was sent around the office, consider the following two classes:

    class Foo
    int _foo;
    void SetFoo(int foo) { _foo = foo; }
    int GetFoo() const { return _foo; }

    class Bar
    mutable std::atomic<int> _bar;
    void SetBar(int bar) { _bar = bar; }
    int GetBar() const { return _bar; }

    They present the exact same interface to the user, though they definitely expect to be used in different ways. Should Bar::SetBar be a const method to mark it as thread safe? To me, this is the same as saying concurrent_queue::push should be a const method.

  • User profile image
    Odin Holmes

    At 57:00 shouldn't the lambdas be capturing by reference? I don't see how [=]{done=true;} is going to work if done is captured by value.

  • User profile image

    Great talk. Though I have to say this wrapper pattern has been pretty common in the C# world for a while (sans operator())

  • User profile image

    While herb explains about concuurent <T> with return type, how is he able to capture promise by value where its move only type?

Add Your 2 Cents