Threads and Shared Variables in C++11
- Date: February 2, 2012 from 11:15AM to 12:15PM
- Day 1
- Speakers: Hans Boehm
- 35,029 Views
- 9 Comments
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.
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.
Follow the Discussion
Are slides going to be published at some point?
I'm interested in the slides too, I missed the keynote and the first part of Hans's session
@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.
C
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.
@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).
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.
Thanks!
We definitely need more info on what we can and can't do.
There's a missing bracket on slide 52. 8 - )
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?
Remove this comment
Remove this thread
close