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

84 CHAPTER 8. DEFERRED PROCESSING12000rwlock readerrwlock readerrwlock readerspinspinspinspinrwlock writerrwlock readerrwlock readerrwlock readerOverhead (nanoseconds)100008000600040002000rwlockrcu00 2 4 6 8 10Critical-Section Duration (microseconds)Figure 8.17: Comparison of RCU to Reader-WriterLocking as Function of Critical-Section Durationpossible for them to participate in a deadlock cycle.Quick Quiz 8.14: Is there an exception to thisdeadlock immunity, and if so, what sequence ofevents could lead to deadlock?An interesting consequence of RCU’s read-sidedeadlock immunity is that it is possible to unconditionallyupgrade an RCU reader to an RCU updater.Attempting to do such an upgrade withreader-writer locking results in deadlock. A samplecode fragment that does an RCU read-to-updateupgrade follows:1 rcu_read_lock();2 list_for_each_entry_rcu(p, \&head, list_field) {3 do_something_with(p);4 if (need_update(p)) {5 spin_lock(\my_lock);6 do_update(p);7 spin_unlock(\&my_lock);8 }9 }10 rcu_read_unlock();Notethatdo_update() isexecuted undertheprotectionof the lock and under RCU read-side protection.Another interesting consequence of RCU’s deadlockimmunity is its immunity to a large class of priorityinversion problems. For example, low-priorityRCU readers cannot prevent a high-priority RCUupdater from acquiring the update-side lock. Similarly,a low-priority RCU updater cannot preventhigh-priority RCU readers from entering an RCUread-side critical section.RCU readerRCU readerRCU readerUpdate ReceivedRCU readerRCU readerRCU readerRCU updaterRCU readerRCU readerRCU readerTimeFigure 8.18: Response Time of RCU vs. Reader-Writer LockingRealtime Latency Because RCU read-side primitivesneither spin nor block, they offer excellent realtimelatencies. In addition, as noted earlier, thismeans that they are immune to priority inversioninvolving the RCU read-side primitives and locks.However, RCU is susceptible to more subtlepriority-inversion scenarios, for example, a highpriorityprocess blocked waiting for an RCU graceperiod to elapse can be blocked by low-priority RCUreaders in -rt kernels. This can be solved by usingRCU priority boosting [McK07d, GMTW08].RCU Readers and Updaters Run ConcurrentlyBecause RCU readers never spin nor block,and because updaters are not subject to any sortof rollback or abort semantics, RCU readers andupdaters must necessarily run concurrently. Thismeans that RCU readers might access stale data,and might even see inconsistencies, either of whichcan render conversion from reader-writer locking toRCU non-trivial.However, in a surprisingly large number of situations,inconsistencies and stale data are not problems.The classic example is the networking routingtable. Because routing updates can take considerabletime to reach a given system (seconds or evenminutes), the system will have been sending packetsthe wrong way for quite some time when the updatearrives. It is usually not a problem to continuesending updates the wrong way for a few additionalmilliseconds. Furthermore, because RCU updaterscan make changes without waiting for RCU readersto finish, the RCU readers might well see thechange more quickly than would batch-fair readerwriter-lockingreaders, as shown in Figure 8.18.Once the update is received, the rwlock writer