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

302 APPENDIX F. ANSWERS TO QUICK QUIZZESoverhead of the update-side code. Any productionuses of this code would be better served by usingthe poll() system call, but then again, productionuses would be even better served by otherimplementations shown later in this section.Quick Quiz 8.41:Why not simply make rcu_read_lock() wait whena concurrent synchronize_rcu() has been waitingtoo long in the RCU implementation in Figure 8.29?Wouldn’t that prevent synchronize_rcu() fromstarving?Answer:Although this would in fact eliminate the starvation,it would also mean that rcu_read_lock()would spin or block waiting for the writer, whichis in turn waiting on readers. If one of thesereaders is attempting to acquire a lock that thespinning/blocking rcu_read_lock() holds, weagain have deadlock.In short, the cure is worse than the disease. SeeSection 8.3.4.4 for a proper cure.Quick Quiz 8.42:Why the memory barrier on line 5 ofsynchronize_rcu() in Figure 8.32 given thatthere is a spin-lock acquisition immediately after?Answer:The spin-lock acquisition only guarantees that thespin-lock’s critical section will not “bleed out” toprecede the acquisition. It in no way guaranteesthat code preceding the spin-lock acquisitoin won’tbe reordered into the critical section. Such reorderingcould cause a removal from an RCU-protectedlist to be reordered to follow the complementing ofrcu_idx, which could allow a newly starting RCUread-side critical section to see the recently removeddata element.Exercise for the reader: use a tool such asPromela/spin to determine which (if any) of thememory barriers in Figure 8.32 are really needed.See Section E for information on using these tools.The first correct and complete response will be credited.Quick Quiz 8.43:Why is the counter flipped twice in Figure 8.32?Shouldn’t a single flip-and-wait cycle be sufficient?Answer:Both flips are absolutely required. To see this,consider the following sequence of events:1. Line 8 of rcu_read_lock() in Figure 8.31 picksup rcu_idx, finding its value to be zero.2. Line 8 of synchronize_rcu() in Figure 8.32complements the value of rcu_idx, setting itsvalue to one.3. Lines10-13ofsynchronize_rcu()findthatthevalue of rcu_refcnt[0] is zero, and thus returns.(Recall that the question is asking whathappens if lines 14-20 are omitted.)4. Lines 9 and 10 of rcu_read_lock() store thevalue zero to this thread’s instance of rcu_read_idx and increments rcu_refcnt[0], respectively.Execution then proceeds into theRCU read-side critical section.5. Another instance of synchronize_rcu() againcomplements rcu_idx, this time setting itsvalue to zero. Because rcu_refcnt[1] is zero,synchronize_rcu() returns immediately. (Recallthat rcu_read_lock() incremented rcu_refcnt[0], not rcu_refcnt[1]!)6. The grace period that started in step 5 has beenallowed to end, despite the fact that the RCUread-side critical section that started beforehandin step 4 has not completed. This violatesRCU semantics, and could allow the update tofree a data element that the RCU read-side criticalsection was still referencing.Exercise for the reader: What happens if rcu_read_lock() is preempted for a very long time(hours!) just after line 8? Does this implementationoperate correctly in that case? Why or whynot? The first correct and complete response will becredited.Quick Quiz 8.44:Given that atomic increment and decrement are soexpensive, why not just use non-atomic incrementon line 10 and a non-atomic decrement on line 25 ofFigure 8.31?Answer:Using non-atomic operations would cause incrementsand decrements to be lost, in turn causingthe implementation to fail. See Section 8.3.4.5