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

4.4. EXACT LIMIT COUNTERS 43Quick Quiz 4.39: In Figure 4.21 functionflush_local_count_sig(), why are there ACCESS_ONCE() wrappers around the uses of the theft perthreadvariable?Lines 21-49 shows flush_local_count(), whichis called from the slowpath to flush all threads’ localcounts. The loop spanning lines 26-34 advances thetheft state for each thread that has local count,and also sends that thread a signal. Line 27 skipsany non-existent threads. Otherwise, line 28 checksto see if the current thread holds any local count,and, if not, line 29 sets the thread’s theft stateto READY and line 28 skips to the next thread.Otherwise, line 32 sets the thread’s theft state toREQ and line 29 sends the thread a signal.Quick Quiz 4.40: In Figure 4.21, why is itsafe for line 28 to directly access the other thread’scountermax variable?Quick Quiz 4.41: In Figure 4.21, why doesn’tline 33 check for the current thread sending itself asignal?Quick Quiz 4.42: ThecodeinFigure4.21, workswith gcc and POSIX. What would be required tomake it also conform to the ISO C standard?The loop spanning lines 35-48 waits until eachthread reaches READY state, then steals thatthread’s count. Lines 36-37 skip any non-existentthreads, and the loop spanning lines 38-42 wait untilthe current thread’s theft state becomes READY.Line 39 blocks for a millisecond to avoid priorityinversionproblems, and if line 40 determines thatthe thread’s signal has not yet arrived, line 41 resendsthe signal. Execution reaches line 43 when thethread’s theft state becomes READY, so lines 43-46 do the thieving. Line 47 then sets the thread’stheft state back to IDLE.Quick Quiz 4.43: In Figure 4.21, why doesline 41 resend the signal?Lines 51-63 show balance_count(), which is similarto that of earlier examples.Lines 1-36 of Figure 4.22 shows the add_count()function. The fastpath spans lines 5-20, and theslowpath lines 21-35. Line 5 sets the per-threadcounting variable to1sothat any subsequent signalhandlers interrupting this thread will set the theftstate to ACK rather than READY, allowing thisfastpath to complete properly. Line 6 prevents thecompiler from reordering any of the fastpath bodyto preceed the setting of counting. Lines 7 and 8check to see if the per-thread data can accommodatethe add_count() and if there is no ongoing theft inprogress, and if so line 9 does the fastpath additionand line 10 notes that the fastpath was taken.In either case, line 12 prevents the compiler from1 int add_count(unsigned long delta)2 {3 int fastpath = 0;45 counting = 1;6 barrier();7 if (countermax - counter >= delta &&8 ACCESS_ONCE(theft) = delta &&45 ACCESS_ONCE(theft)