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

F.7. CHAPTER 8: DEFERRED PROCESSING 297beyond a certain point, the code fragments look thesame. The only difference is in how we think aboutthe code. However, this difference can be extremelyimportant. For but one example of the importance,consider that if we think of RCU as a restrictedreference counting scheme, we would never be fooledinto thinking that the updates would exclude theRCU read-side critical sections.It nevertheless is often useful to think of RCU as areplacement for reader-writer locking, for example,when you are replacing reader-writer locking withRCU.Quick Quiz 8.16:Why the dip in refcnt overhead near 6 CPUs?Answer:Most likely NUMA effects. However, there issubstantial variance in the values measured for therefcnt line, as can be seen by the error bars. In fact,standard deviations range in excess of 10values insome cases. The dip in overhead therefore mightwell be a statistical aberration.Quick Quiz 8.17:What if the element we need to delete is not thefirst element of the list on line 9 of Figure 8.24?Answer:As with Figure 6.1, this is a very simple hash tablewith no chaining, so the only element in a givenbucket is the first element. The reader is againinvited to adapt this example to a hash table withfull chaining.Quick Quiz 8.18:Why is it OK to exit the RCU read-side criticalsection on line 15 of Figure 8.24 before releasing thelock on line 17?Answer:First, please note that the second check on line 14is necessary because some other CPU might haveremoved this element while we were waiting toacquire the lock. However, the fact that we were inan RCU read-side critical section while acquiringthe lock guarantees that this element could notpossibly have been re-allocated and re-insertedinto this hash table. Furthermore, once we acquirethe lock, the lock itself guarantees the element’sexistence, so we no longer need to be in an RCUread-side critical section.The question as to whether it is necessary to recheckthe element’s key is left as an exercise to thereader.Quick Quiz 8.19:Why not exit the RCU read-side critical section online 23 of Figure 8.24 before releasing the lock online 22?Answer:Suppose we reverse the order of these two lines.Then this code is vulnerable to the followingsequence of events:1. CPU 0 invokes delete(), and finds the elementto be deleted, executing through line 15. Ithas not yet actually deleted the element, butis about to do so.2. CPU 1 concurrently invokes delete(), attemptingto delete this same element. However,CPU 0 still holds the lock, so CPU 1 waits forit at line 13.3. CPU 0 executes lines 16 and 17, and blocks atline 18 waiting for CPU 1 to exit its RCU readsidecritical section.4. CPU 1 now acquires the lock, but the test online14failsbecauseCPU0hasalreadyremovedtheelement. CPU1nowexecutesline22(whichwe switched with line 23 for the purposes of thisQuick Quiz) and exits its RCU read-side criticalsection.5. CPU 0 can now return from synchronize_rcu(), and thus executes line 19, sending theelement to the freelist.6. CPU 1 now attempts to release a lock for anelement that has been freed, and, worse yet,possibly reallocated as some other type of datastructure. This is a fatal memory-corruptionerror.Quick Quiz 8.20:But what if there is an arbitrarily long series of RCUread-side critical sections in multiple threads, sothat at any point in time there is at least one threadin the system executing in an RCU read-side criticalsection? Wouldn’t that prevent any data from aSLAB_DESTROY_BY_RCU slab ever being returnedtothesystem, possiblyresultinginOOMevents?