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

CppCon.org
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/CppCon/CppCon2017
-
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.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*

[@jimlin897]

Wonderful talk! Thanks!

[@almightysquirrel4679]

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

[@andmefikri7555]

Thank you! This talk was amazing :D

[@CppCon]

Glad it was helpful!

[@hazemzamalkawy14]

Thank you really great video.

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

[@aniketbisht2823]

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

[@on-hv9co]

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?

[@guillaumecourrier7489]

I don't think this is the case. If you look at the synchronize_rcu implementation that was shown, it will store the current generation value N in last_gen and will do the cleanup of each generation from last_gc_gen to last_gen excluded. So if a reader grabs generation N the writter will do the cleanup up to N - 1. I think synchronize_rcu will not cleanup the memory of the current and previous generations in the code that was shown.

[@Ricky-kx6pf]

@@guillaumecourrier7489 Please correct me, what if synchronize_rcu is called twice between the execution of the generation load and the refcount increment?

[@jjaychen]

@@Ricky-kx6pfCurious about this, too. Did you figure it out?

[@sunjc826]

@@jjaychen I was thinking you could do a double check, before getting the handle and after getting the handle, and return the handle only when the generation count has not changed. That way, you can guarantee the increment was registered. Somewhat similar to what the SeqLock does?

[@blah0123455]

I had the same question. I think a loop that does a double check makes sense. It would guarantee correctness, and If the generation isn't updated often, then most of the time the generation numbers would match and so the double check loop wouldn't be too costly either.

[@kamalabuhenamostafa]

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