Is Parallel Programming Hard, And, If So, What Can You Do About It?

232 APPENDIX D. READ-COPY UPDATE IMPLEMENTATIONSlimitations, and this appendix describes its design,serving as an update to the LWN article [McK07a].However, please note that this implementation wasreplacedwithafasterandsimplerimplementationinthe 2.6.32 Linux kernel. This description neverlessremains to bear witness to the most complex RCUimplementation ever devised.Quick Quiz D.56: Why is it importantthat blocking primitives called from within apreemptible-RCU read-side critical section be subjectto priority inheritance?Quick Quiz D.57: Could theprohibition againstusing primitives that would block in a non-CONFIG_PREEMPT kernel be lifted, and if so, under what conditions?D.4.1 Conceptual RCUUnderstanding and validating an RCU implementationis much easier given a view of RCU at thelowest possible level. This section gives a very briefoverviewofthemostbasicconcurrencyrequirementsthat an RCU implementation must support. Formore detail, please see Section 8.3.1.RCU implementations must obey the followingrule: if any statement in a given RCU read-side criticalsection precedes a grace period, then all statementsin that RCU read-side critical section mustcomplete before that grace period ends.Reader Reader ReaderReaderRemovalReaderReaderReaderReaderForbidden!ReaderReclamationFigure D.58: Buggy Grace Period From BrokenRCUThis is illustrated by Figure D.58, where time advancesfrom left to right. The red ”Removal” boxrepresents the update-side critical section that modifiesthe RCU-protected data structure, for example,via list_del_rcu(); the large yellow ”Grace Period”boxrepresentsagraceperiod(surprise!)whichmight be invoked via synchronize_rcu(), and thegreen ”Reclamation” box represents freeing the affecteddata element, perhaps via kfree(). The blue”Reader” boxes each represent an RCU read-sidecritical section, for example, beginning with rcu_read_lock() and ending with rcu_read_unlock().The red-rimmed ”Reader” box is an example of anillegal situation: any so-called RCU implementationthat permits a read-side critical section to completelyoverlap a grace period is buggy, since theupdater might free up memory that this reader isstill using.So, what is the poor RCU implementation to doin this situation?Reader Reader ReaderReaderRemovalReaderReaderReaderReaderGrace PeriodExtends asNeededReaderReclamationFigureD.59: GoodGracePeriodFromCorrectRCUIt must extend the grace period, perhaps as shownin Figure D.59. In short, the RCU implementationmust ensure that any RCU read-side critical sectionsin progress at the start of a given grace period havecompletely finished, memory operations and all, beforethatgraceperiodispermittedtocomplete.Thisfact allows RCU validation to be extremely focused:simply demonstrate that any RCU read-side criticalsection in progress at the beginning of a grace periodmust terminate before that grace period ends,along with sufficient barriers to prevent either thecompiler or the CPU from undoing the RCU implementation’swork.D.4.2 Overview of Preemptible RCUAlgorithmThis section focuses on a specific implementationof preemptible RCU. Many other implementationsare possible, and are described elsewhere [MSMB06,MS05]. This article focuses on this specific implementation’sgeneral approach, the data structures,the grace-period state machine, and a walk throughthe read-side primitives.D.4.2.1 General ApproachBecause this implementation of preemptible RCUdoes not require memory barriers in rcu_read_lock() and rcu_read_unlock(), a multi-stage