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

F.4. CHAPTER 4: COUNTING 287Quick Quiz 4.32:Yecch!!! Why the ugly goto on line 11 ofFigure 4.16? Haven’t you heard of the breakstatement???Answer:Replacing the goto with a break would requirekeeping a flag to determine whether or not line 15should return, which is not the sort of thing youwant on a fastpath. If you really hate the goto thatmuch, your best bet would be to pull the fastpathinto a separate function that returned success orfailure, with “failure” indicating a need for theslowpath. This is left as an exercise for goto-hatingreaders.Quick Quiz 4.33:Why would the atomic_cmpxchg() primitive atlines 13-14 of Figure 4.16 ever fail? After all, wepicked up its old value on line 9 and have notchanged it!Answer:Later, we will see how the flush_local_count()function in Figure 4.18 might update this thread’scounterandmax variable concurrently with the executionof the fastpath on lines 8-14 of Figure 4.16.Quick Quiz 4.34:What stops a thread from simply refillingits counterandmax variable immediately afterflush_local_count() on line 14 of Figure 4.18empties it?Answer:This other thread cannot refill its counterandmaxuntil the caller of flush_local_count() releasesthe gblcnt_mutex. By that time, the caller offlush_local_count() will have finished makinguse of the counts, so there will be no problem withthis other thread refilling — assuming that thevalue of globalcount is large enough to permit arefill.Quick Quiz 4.35:What prevents concurrent execution of the fastpathof either atomic_add() or atomic_sub() frominterfering with the counterandmax variable whileflush_local_count() is accessing it on line 27 ofFigure 4.18 empties it?Answer:Nothing. Consider the following three cases:1. Ifflush_local_count()’satomic_xchg()executesbefore the split_counterandmax() of eitherfastpath, then the fastpath will see a zerocounter and countermax, and will thus transferto the slowpath (unless of course delta iszero).2. If flush_local_count()’s atomic_xchg()executes after the split_counterandmax()of either fastpath, but before that fastpath’satomic_cmpxchg(), then theatomic_cmpxchg() will fail, causing thefastpath to restart, which reduces to case 1above.3. If flush_local_count()’s atomic_xchg() executesafter the atomic_cmpxchg() of eitherfastpath, then the fastpath will (most likely)complete successfully before flush_local_count() zeroes the thread’s counterandmaxvariable.Either way, the race is resolved correctly.Quick Quiz 4.36:Given that the atomic_set() primitive does asimple store to the specified atomic_t, how canline 53 of balance_count() in Figure 4.18 work correctlyin face of concurrent flush_local_count()updates to this variable?Answer:The caller of both balance_count() andflush_local_count() hold gblcnt_mutex, soonly one may be executing at a given time.Quick Quiz 4.37:In Figure 4.19, why is the REQ theft state coloredblue?Answer:To indicate that only the fastpath is permitted tochange the theft state.Quick Quiz 4.38:In Figure 4.19, what is the point of having separateREQ and ACK theft states? Why not simplifythe state machine by collapsing them into a singlestate? Then whichever of the signal handler orthe fastpath gets there first could set the state to