Threads and Shared Variables in C++11

Play Threads and Shared Variables in C++11
Sign in to queue


The C++11 standard introduces threads into the language, and carefully defines the meaning of variables shared between threads. The design is based on the idea that meaningful multithreaded programs should, by default, behave as though threads were executed in simple interleaved fashion. This allows efficient execution only because "data races" (simultaneous non-read-only accesses to shared variables) are disallowed.  Although this basic approach is shared with some other languages, and with threads interfaces like pthreads, we tried hard to avoid their mistakes.  For example, C++11 provides a comprehensive atomic operations library, which makes it much more feasible to avoid data races in real low-level code.

I'll give a very quick overview of thread support in C++11, and then focus on the behavior of shared variables, often called the "memory model". I'll try to explain why, after more than 40 years of programming with shared variables, shared variables and atomic operations were still controversial, and why the C++11 approach is the right one.


C++11, C++







Right click to download this episode

The Discussion

  • User profile image

    Are slides going to be published at some point?

  • User profile image

    I'm interested in the slides too, I missed the keynote and the first part of Hans's session

  • User profile image

    @El Cubico That's utterly useless...  Recommended to not download, it's just El Cubico's bad manner upon Boehm's talk concerning his foreign accent. I actually want to hear the content not your ridiculous edit.

  • User profile image

    , HeavensRevenge wrote

    @El Cubico That's utterly useless...  Recommended to not download, it's just El Cubico's bad manner upon Boehm's talk concerning his foreign accent. I actually want to hear the content not your ridiculous edit.

    I agree. Removed.


  • User profile image
    Javier Estrada

    In slide 33 Hans has a typo at the bottom of the page:

    Frequently breaks repeatably in practice.

    Should read:

    Frequently breaks repeatedly in practice.

  • User profile image

    @Javier Estrada: No, I don't think it's a typo. He actually means 'repeatably', as in 'in a repeatable way'.

    He actually explains during the talk that compilers will typically treat the 'done' variable as a loop invariant and only read it once, which means the loop will either execute forever or not at all - a predictable, repeatable, behaviour (not the more-common unpredictable mess that you may get from programs containing data races).

  • User profile image

    The example on slide 36:

    I understand what it says. But isn't this a too high performance hit? On the one hand one gives the compiler lots of freedom and one has to ensure proper memory barriers for a single variable. But for variables that are next to each other everything has to be synchronized properly by the compiler.

    For current architectures protecting neighbouring variables might be a different issue than protecting the same variable. But how about possible future systems where neighbouring variables have to be treated in the same way as a single one when it comes to concurrent access by different cpus? When the number of cpus in a system goes into the thousands the necessary cache coherence protocol traffic might forbid the current model.

  • User profile image

    We definitely need more info on what we can and can't do.
    There's a missing bracket on slide 52. 8 - )

  • User profile image

    Approx 35 minutes in, Hans talks about data races for objects as opposed to primitive types. The "rule of thumb" seems to be that library implementers should provide the same model for objects as the standard does for primitive types.

    I guess an object "read" equates to a const method call, and an object "write" equates to a non-const method call.

    Does anyone know if this is actually part of the standard? Can I assume that multiple threads calling const methods on an object is safe from any C++11 compiler/library?

Add Your 2 Cents