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

15.1. TRANSACTIONAL MEMORY 1513. Treat the transaction in a manner similar tonon-persistent Locking primitives, so that thetransaction survives if exec() fails, and silentlycommits if the exec() succeeds. The case weresomeofthevariablesaffectedbythetransactionresideinmmap()edmemory(andthuscouldsurvivea successful exec() system call) is left asan exercise for the reader.4. Abort the transaction (and the exec() systemcall) if the exec() system call would have succeeded,but allow the transaction to continueif the exec() system call would fail. This is insome sense the “correct” approach, but it wouldrequire considerable work for a rather unsatisfyingresult.The exec() system call is perhaps the strangestexampleofanobstacletouniversalTMapplicability,as it is not completely clear what approach makessense, and some might argue that this is merely a reflectionof the perils of interacting with execs in reallife. That said, the two options prohibiting exec()within transactions are perhaps the most logical ofthe group.15.1.13 RCUBecause read-copy update (RCU) finds its main usein the Linux kernel, one might be forgiven for assumingthat there had been no academic work oncombining RCU and TM. However, the TxLinuxgroup from the University of Texas at Austin hadno choice [RHP + 07]. The fact that they appliedTM to the Linux 2.6 kernel, which uses RCU, forcedthemtointegrateTMandRCU,withTMtakingtheplace of locking for RCU updates. Unfortunately,although the paper does state that the RCU implementation’slocks (e.g., rcu_ctrlblk.lock) wereconverted to transactions, it is silent about whathappened to locks used in RCU-based updates (e.g.,dcache_lock).It is important to note that RCU permits readersandupdaterstorunconcurrently, furtherpermittingRCUreaderstoaccessdatathatisintheactofbeingupdated. Of course, this property of RCU, whateverits performance, scalability, and real-time-responsebenefits might be, flies in the face of the underlyingatomicity properties of TM.So how should TM-based updates interact withconcurrent RCU readers? Some possibilities are asfollows:1. RCU readers abort concurrent conflicting TMupdates. This is in fact the approach taken bythe TxLinux project. This approach does preserveRCU semantics, and also preserves RCU’sread-side performance, scalability, and realtime-responseproperties, but it does have theunfortunate side-effect of unnecessarily abortingconflicting updates. In the worst case, along sequence of RCU readers could potentiallystarve all updaters, which could in theory resultin system hangs. In addition, not all TM implementationsoffer the strong atomicity requiredto implement this approach.2. RCU readers that run concurrently with conflictingTM updates get old (pre-transaction)values from any conflicting RCU loads. Thispreserves RCU semantics and performance, andalsopreventsRCU-updatestarvation. However,not all TM implementations can provide timelyaccess to old values of variables that have beententatively updated by an in-flight transaction.In particular, log-based TM implementationsthatmaintainoldvaluesinthelog(thusmakingfor excellent TM commit performance) are notlikely to be happy with this approach. Perhapsthe rcu_dereference() primitive can be leveragedto permit RCU to access the old valueswithin a greater range of TM implementations,though performance might still be an issue.3. If an RCU reader executes an access that conflictswith an in-flight transaction, then thatRCU access is delayed until the conflictingtransaction either commits or aborts. Thisapproach preserves RCU semantics, but notRCU’s performance or real-time response, particularlyin presence of long-running transactions.In addition, not all TM implementationsare capable of delaying conflicting accesses.That said, this approach seems eminentlyreasonable for hardware TM implementationsthat support only small transactions.4. RCU readers are converted to transactions.This approach pretty much guarantees thatRCU is compatible with any TM implementation,butitalsoimposesTM’srollbacksonRCUread-side critical sections, destroying RCU’sreal-time response guarantees, and also degradingRCU’sread-sideperformance.Furthermore,this approach is infeasible in cases where any ofthe RCU read-side critical sections contains operationsthat the TM implementation in questionis incapable of handling.5. Many update-side uses of RCU modify a singlepointer to publish a new data structure. In