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

288 APPENDIX F. ANSWERS TO QUICK QUIZZESREADY.Answer:Reasons why collapsing the REQ and ACK stateswould be a very bad idea include:1. The slowpath uses the REQ and ACK statesto determine whether the signal should be retransmitted.If the states were collapsed, theslowpath would have no choice but to send redundantsignals, which would have the unhelpfuleffect of slowing down the fastpath.2. The following race would result:(a) The slowpath sets a given thread’s state toREQACK.(b) That thread has just finished its fastpath,and notes the REQACK state.(c) The thread receives the signal, which alsonotes the REQACK state, and, becausethere is no fastpath in effect, sets the stateto READY.(d) The slowpath notes the READY state,steals the count, and sets the state toIDLE, and completes.(e) ThefastpathsetsthestatetoREADY,disablingfurther fastpath execution for thisthread.The basic problem here is that the combinedREQACK state can be referenced by both thesignal handler and the fastpath. The clear separationmaintained by the four-state setup ensuresorderly state transitions.That said, you might well be able to make a threestatesetup work correctly. If you do succeed, comparecarefully to the four-state setup. Is the threestatesolution really preferable, and why or why not?Quick Quiz 4.39:In Figure 4.21 function flush_local_count_sig(),why are there ACCESS_ONCE() wrappers around theuses of the theft per-thread variable?Answer:The first one (on line 11) can be argued to beunnecessary. The last two (lines 14 and 16) areimportant. If these are removed, the compiler wouldbe within its rights to rewrite lines 14-17 as follows:14 theft = THEFT_READY;15 if (counting) {16 theft = THEFT_ACK;17 }This would be fatal, as the slowpath might see thetransient value of THEFT_READY, and start stealingbefore the corresponding thread was ready.Quick Quiz 4.40:In Figure 4.21, why is it safe for line 28 to directlyaccess the other thread’s countermax variable?Answer:Because the other thread is not permitted to changethe value of its countermax variable unless it holdsthe gblcnt_mutex lock. But the caller has acquiredthis lock, so it is not possible for the other threadto hold it, and therefore the other thread is notpermitted to change its countermax variable. Wecan therefore safely access it — but not change it.Quick Quiz 4.41:In Figure 4.21, why doesn’t line 33 check for thecurrent thread sending itself a signal?Answer:There is no need for an additional check. Thecaller of flush_local_count() has already invokedglobalize_count(), so the check on line 28 willhave succeeded, skipping the later pthread_kill().Quick Quiz 4.42:The code in Figure 4.21, works with gcc and POSIX.What would be required to make it also conform tothe ISO C standard?Answer:The theft variable must be of type sig_atomic_tto guarantee that it can be safely shared betweenthe signal handler and the code interrupted by thesignal.Quick Quiz 4.43:In Figure 4.21, why does line 41 resend the signal?Answer:Because many operating systems over severaldecades have had the property of losing the occasionalsignal. Whether this is a feature or a bug isdebatable, but irrelevant. The obvious symptomfrom the user’s viewpoint will not be a kernel bug,but rather a user application hanging.