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

F.15. CHAPTER D: READ-COPY UPDATE IMPLEMENTATIONS 313Suppose that lines 3-5 for CPUs 1 and 2 in Table C.4are in an interrupt handler, and that the CPU 2’sline 9 is run at process level. What changes, if any,are required to enable the code to work correctly, inother words, to prevent the assertion from firing?Answer:The assertion will need to written to ensure thatthe load of “e” precedes that of “a”. In the Linuxkernel, the barrier() primitive may be used toaccomplish this in much the same way that thememory barrier was used in the assertions in theprevious examples.F.15 Chapter D: Read-CopyUpdate ImplementationsQuick Quiz D.1:Why is sleeping prohibited within Classic RCUread-side critical sections?Answer:Because sleeping implies a context switch, whichin Classic RCU is a quiescent state, and RCU’sgrace-period detection requires that quiescent statesnever appear in RCU read-side critical sections.Quick Quiz C.12:If CPU 2 executed an assert(e==0||c==1) inthe example in Table C.4, would this assert evertrigger?Answer:The result depends on whether the CPU supports“transitivity.” In other words, CPU 0 stored to “e”after seeing CPU 1’s store to “c”, with a memorybarrier between CPU 0’s load from “c” and store to“e”. If some other CPU sees CPU 0’s store to “e”,is it also guaranteed to see CPU 1’s store?All CPUs I am aware of claim to provide transitivity.Quick Quiz C.13:Why is Alpha’s smp_read_barrier_depends() ansmp_mb() rather than smp_rmb()?Answer:First, Alpha has only mb and wmb instructions, sosmp_rmb() would be implemented by the Alpha mbinstruction in either case.More importantly, smp_read_barrier_depends() must order subsequent stores. Forexample, consider the following code:Quick Quiz D.2:Why not permit sleeping in Classic RCU read-sidecritical sections by eliminating context switch as aquiescent state, leaving user-mode execution andidle loop as the remaining quiescent states?Answer:This would mean that a system undergoing heavykernel-mode execution load (e.g., due to kernelthreads) might never complete a grace period,which would cause it to exhaust memory sooner orlater.Quick Quiz D.3:Why is it OK to assume that updates separated bysynchronize sched() will be performed in order?Answer:Because this property is required for thesynchronize sched() aspect of RCU to workat all. For example, consider a code sequencethat removes an object from a list, invokessynchronize sched(), then frees the object. Ifthis property did not hold, then that object mightappear to be freed before it was removed fromthe list, which is precisely the situation thatsynchronize sched() is supposed to prevent!1 p = global_pointer;2 smp_read_barrier_depends();3 if (do_something_with(p->a, p->b) == 0)4 p->hey_look = 1;Here the store to p->hey_look must be ordered,not just the loads from p->a and p->b.Quick Quiz D.4:Why must line 17 in synchronize srcu() (FigureD.10) precede the release of the mutex online 18? What would have to change to permitthese two lines to be interchanged? Would such achange be worthwhile? Why or why not?