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

F.3. CHAPTER 3: TOOLS OF THE TRADE 279Quick Quiz 3.10:Writing four lines of code for each acquisition andrelease of a pthread_mutex_t sure seems painful!Isn’t there a better way?Answer:Indeed! And for that reason, the pthread_mutex_lock() and pthread_mutex_unlock() primitivesare normally wrappered in functions that do thiserror checking. Later on, we will wrapper them withthe Linux kernel spin_lock() and spin_unlock()APIs.Quick Quiz 3.11:Is “x = 0” the only possible output from the codefragment shown in Figure 3.7? If so, why? If not,what other output could appear, and why?Answer:No. The reason that “x = 0” was output wasthat lock_reader() acquired the lock first. Hadlock_writer() instead acquired the lock first, thenthe output would have been “x = 3”. However,because the code fragment started lock_reader()first and because this run was performed ona multiprocessor, one would normally expectlock_reader() to acquire the lock first. However,there are no guarantees, especially on a busysystem.Quick Quiz 3.12:Using different locks could cause quite a bit ofconfusion, what with threads seeing each others’intermediate states. So should well-written parallelprograms restrict themselves to using a single lockin order to avoid this kind of confusion?Answer:Although it is sometimes possible to write a programusing a single global lock that both performsand scales well, such programs are exceptions to therule. You will normally need to use multiple locksto attain good performance and scalability.One possible exception to this rule is “transactionalmemory”, which is currently a research topic.Transactional-memory semantics can be thought ofas those of a single global lock with optimizationspermitted and with the addition of rollback [Boe09].Quick Quiz 3.13:In the code shown in Figure 3.8, is lock_reader()guaranteed to see all the values produced bylock_writer()? Why or why not?Answer:No. On a busy system, lock_reader()might be preempted for the entire duration oflock_writer()’s execution, in which case it wouldnot see any of lock_writer()’s intermediate statesfor x.Quick Quiz 3.14:Wait a minute here!!! Figure 3.7 didn’t initializeshared variable x, so why does it need to beinitialized in Figure 3.8?Answer:See line 3 of Figure 3.6. Because the code in Figure3.7 ran first, it could rely on the compile-timeinitialization of x. The code in Figure 3.8 ran next,so it had to re-initialize x.Quick Quiz 3.15:Isn’t comparing against single-CPU throughput abit harsh?Answer:Not at all. In fact, this comparison was, if anything,overly lenient. A more balanced comparison wouldbe against single-CPU throughput with the lockingprimitives commented out.Quick Quiz 3.16:But 1,000 instructions is not a particularly smallsize for a critical section. What do I do if I needa much smaller critical section, for example, onecontaining only a few tens of instructions?Answer:If the data being read never changes, then you donot need to hold any locks while accessing it. If thedata changes sufficiently infrequently, you might beable to checkpoint execution, terminate all threads,change the data, then restart at the checkpoint.Another approach is to keep a single exclusivelock per thread, so that a thread read-acquires thelarger aggregate reader-writer lock by acquiring itsown lock, and write-acquires by acquiring all theper-thread locks [HW92]. This can work quite wellfor readers, but causes writers to incur increasinglylarge overheads as the number of threads increases.