CppCon 2017: Fedor Pikus “Read, Copy, Update, then what? RCU for non-kernel programmers”

—
—
RCU (Read, Copy, Update) is often the highest-performing way to implement concurrent data structures. The differences in performance between an RCU implementation and the next best alternative can be striking. And yet, RCU algorithms have received little attention outside of the world of kernel programming. Largely, this is because the most common drawback of RCU solution is complicated, and often wasteful, memory management. Kernel code has some advantages here, whereas a generic solution is much harder to design.

There are, however, cases when RCU is simple to use, offers very high performance, and the memory issues are easy to manage. In fact, you may already be using the RCU approach in your program without realizing it! Wouldn't that be cool? But careful now: you may be already using the RCU approach in your program in a subtly wrong way. I'm talking about the kind of way that makes your program pass every test you can throw at it and then crash in front of your most important customer (but only when they run their most critical job, not when you try to reproduce the problem).

In the more general case, we have to confront the problems of RCU memory management, but the reward of much higher performance can make it well worth the effort.

This talk will give you understanding of how RCU works, what makes it so efficient, and what are the conditions and restrictions for a valid application of an RCU algorithm. We focus on using RCU outside of kernel space, so we will have to deal with the problems of memory management... and yes, there will be garbage collection.
—
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.
—

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

[almightysquirrel]

Great video. Everything very intuitively described, I liked video about atomics by Fedor Pikus also. Great job! Waiting for your videos next year, thanks.

[GeorgeTsiros]

17:18 "you do the modulo to get the index of the block and then you do the remainder to get the position of the data in the block", obviously he meant to say "division" (ie quotient), not modulo. (*(p[i/N]))[i%N] or something, i do not remember precedence of dereference

[on-hvco]

Please correct me, because I want to be wrong about this: Isn't there a race condition between rcu_read_lock and synchronize_rcu? lets say a reader grabs generation N, and the current ref count is 0; there is some time between the execution of the generation load and the refcount increment. In this time between generation load and refcount increment, synchronize_rcu is called and gets current generation N and increments it. Before the reader thread has a change to get its increment in, the writer sees that refcount is 0 and proceeds to release the memory. the reader finally comes back to life and attempts to use the handle it was guaranteed to have life time support for but its resource is no longer alive. However improbable, can this race condition occur?

[aniketbisht]

57:13 "Readers can crash", I hope it's not because of undefined behavior.

[kamalabuhenamostafa]

I know that will works, because i write language based, asked data scientist to check our backend,