CppCon 2017: Fedor Pikus “C++ atomics, from basic to advanced. What do they really do?”

—
—
C++11 introduced atomic operations. They allowed C++ programmers to express a lot of control over how memory is used in concurrent programs and made portable lock-free concurrency possible. They also allowed programmers to ask a lot of questions about how memory is used in concurrent programs and made a lot of subtle bugs possible.

This talk analyzes C++ atomic features from two distinct points of view: what do they allow the programmer to express? what do they really do? The programmer always has two audiences: the people who will read the code, and the compilers and machines which will execute it. This distinction is, unfortunately, often missed. For lock-free programming, the difference between the two viewpoints is of particular importance: every time an explicit atomic operation is present, the programmer is saying to the reader of the program "pay attention, something very unusual is going on here." Do we have the tools in the language to precisely describe what is going on and in what way it is unusual? At the same time, the programmer is saying to the compiler and the hardware "this needs to be done exactly as I say, and with maximum efficiency since I went to all this trouble."

This talk starts from the basics, inasmuch as this term can be applied to lock-free programming. We then explore how the C++ lock-free constructs are used to express programmer's intent clearly (and when they get in the way of clarity). Of course, there will be code to look at and to be confused by. At the same time, we never lose track of the fact that the atomics are one of the last resorts of efficiency, and the question of what happens in hardware and how fast does it happen is of paramount importance. Of course, the first rule of performance — "never guess about performance!" — applies, and any claim about speed must be supported by benchmarks.

If you never used C++ atomics but want to learn, this is the talk for you. If you think you know C++ atomics but are unclear on few details, come to fill these few gaps in your knowledge. If you really do know C++ atomics, come to feel good (or to be surprised, and then feel even better).
—
Fedor Pikus: Mentor Graphics - Siemens business, Chief Scientist

Fedor G Pikus is a Chief Engineering Scientist in the Design to Silicon division of Mentor Graphics Corp. His earlier positions included a Senior Software Engineer at Google and a Chief Software Architect for Calibre PERC, LVS, DFM at Mentor Graphics. He joined Mentor Graphics in 1998 when he made a switch from academic research in computational physics to software industry. His responsibilities as a Chief Scientist include planning long-term technical direction of Calibre products, directing and training the engineers who work on these products, design and architecture of the software, and research in new design and software technologies. Fedor has over 25 patents and over 90 papers and conference presentations on physics, EDA, software design, and C++ language.
—

*-----*
*-----*

[TheEmT]

i used to think all these conferences were bs, but man.. these days i just kept watching cppcon when i was supposed to watch memes and vines

[philipye]

Really love this talk, using 1 hour watching this video is actually more efficient than reading cpp reference using a day :)

[dirtbikersteve]

Finally a good explanation of memory orders without hand waving and saying 'it's to complex to worry about'

[sumeshnb]

Finally, this guy made me understand memory ordering. Nice presentation...

[Sychonut]

I really enjoy listening to Fedor. Knowledgeable speaker doing a great job explaining complicated topics.

[blakenev]

This was an amazing talk. I’ve generally had a very loose understanding of memory ordering - enough to know I need to stay away from it. I can confidently say I finally understand it thanks to this.

Rarely will I comment on videos. This video was just too good not to. Hands down one of my favorite talks.

[assonancex]

This talk was superb. Complex topic delivered eloquently. Thanks for that.

[JiveDadson]

I was hoping for a clear explanation of the various std::memory_order types. It starts at 42:26

[BartoszZasieczny]

Best video explaining memory ordering ever.

[EmperorKatax]

great work ... : ), ,
.. in case you like to review a topic again:
// 11:24 limitations for atomic<int>
// 15:40 compare_exchange_strong
// 23:06 atomic vs mutex speed
// 26:30 secret of atomic !
// 33:58 compare_exchange_weak
// 42:12 memory
// 56:48 review

[postdisc]

the most decent and clear explanation of atomics i've seen so far

[szymoniak]

am I the only one who is slightly confused, especially about the memory order part? everyone says this talk is great and all but I'd watched Herb Sutter talk before on atomics and I thought I somewhat understood it and now watched this and now I'm confused

[asdfasdfasdfasdfadsf]

As to the naming of compare_exchange_weak(), from Anthony Williams "C++ Concurrency in Action: Practical Multi threading" pg. 113: "For compare_exchange_weak(), the store might not be successful even if the original value was equal to the expected value, in which case the value of the variable in unchanged and the return value of compare_exchange_weak() is false. This is most likely to to happen on machines that lack a single compare-and-exchange instruction, if the processor can't guarantee that the operation has been done atomically - possibly because the thread performing the operation was switched out tin the middle of the necessary sequence of instructions and another thread scheduled in its place by the operating system where there are more threads than processors. This is called a spurious failure, because the reason for the failure is a function of the timing rather than the values of the variables."

[Gulzt]

Very insightful. Especially with the pictures things fell in the place!

[kpboy]

All these conferences on cppcon are awesome.

[joeybluee]

Great talk, it's the clearest explanation I ever watched.

[flisboac]

Amazing presentation. Learned a lot. Thank you!

[pruibiebehastoet]

Program B (code in 2:20) performs the computation locally and only locks the mutex to store the result. No wonder it is so much faster than A where an atomic read-modify-write has to lock the cache line for each update.. That's comparing apples and oranges.

[scolic]

at 48:00 he is referencing some other talk, about locks?
what video is that?

[mohsenzare]

c++ is beautiful, and this talk is great