Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

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

Download

Right click “Save as…”

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.

Tags:

Follow the Discussion

  • IvanIvan

    @Charles
    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 ? :) )
    P.S.
    for people wanting more of Andrei they can find link for his 3 optimization tips talk on isocpp.org.

  • CharlesCharles Welcome Change
    @Ivan: There are 2 more videos from this series. They will air sometime in the next two weeks.
  • AlastairAlastair

    @charles

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

    I hope so!

    Thanks

  • 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.

  • CharlesCharles Welcome Change

    @Alastair: Nope.

    C

  • Very nice. Thanks for providing these!

    Could the slides be made available for download?  Cool

  • TheNameTheName

    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?^^

  • IvanIvan

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

  • 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?

  • ninety9ninety9

    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?

  • 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

    Lee

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

  • chilachila

    boost::asio cough cough...

    wait() is stupid.

  • chilachila

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

  • 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.

  • 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.

  • Jason ToffalettiJason 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.

    https://github.com/toffaletti/libten/commit/337a390aefc6c2f146021c1f0910df7f2d2d4dd8

    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/

  • kladkukladku

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

  • Great talk, many thanks!

     

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

  • CharlesCharles Welcome Change

    @turck3: http://sdrv.ms/ZJ4EEk

    C

  • @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!

  • loganathanloganathan

    Very nice. Thanks for providing these!

  • CharlesCharles Welcome Change

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

    C

  • J. J. Leejjlee3 jjlee3

    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 {
    private:
        mutable std::mutex m;
    public:
        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.

  • AlastairAlastair

    @herbsutter

    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?

    Regards,



  • Michal MocnyMichal 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?

  • Fernando MFernando 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)
    .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

  • FroglegsFroglegs

    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

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

  • 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?

     

  • AlexanderAlexander

    Herb,

    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.

  • Brian ColeBrian Cole

    Herb,

    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;
    public:
    void SetFoo(int foo) { _foo = foo; }
    int GetFoo() const { return _foo; }
    };

    class Bar
    {
    mutable std::atomic<int> _bar;
    public:
    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.

  • Odin HolmesOdin 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.

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

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.