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

152 CHAPTER 15. CONFLICTING VISIONS OF THE FUTUREsome these cases, RCU can safely be permittedto see a transactional pointer update thatis subsequently rolled back, as long as the transactionrespects memory ordering and as long asthe roll-back process uses call_rcu() to freeup the corresponding structure. Unfortunately,not all TM implementations respect memorybarriers within a tranaction. Apparently, thethought is that because transactions are supposedto be atomic, the ordering of the accesseswithin the transaction is not supposed to matter.6. Prohibit use of TM in RCU updates. This isguaranteed to work, but seems a bit restrictive.It seems likely that additional approaches will beuncovered, especially given the advent of user-levelRCU implementations. 415.1.14 DiscussionThe obstacles to universal TM adoption lead to thefollowing conclusions:1. One interesting property of TM is the factthat transactions are subject to rollback andretry. This property underlies TM’s difficultieswith irreversible operations, including unbufferedI/O, RPCs, memory-mapping operations,time delays, and the exec() system call.This property also has the unfortunate consequenceof introducing all the complexities inherentin the possibility of failure into synchronizationprimitives, often in a developer-visiblemanner.rially, which might do much to explain TM’sissues with multithreaded transactions.What should TM researchers and developers doabout all of this?One approach is to focus on TM in thesmall, focusing on situations where hardware assistpotentially provides substantial advantages overother synchronization primitives. This is in factthe approach Sun took with its Rock researchCPU [DLMN09]. Some TM researchers seem toagree with this approach, while others have muchhigher hopes for TM.Of course, it is quite possible that TM will be ableto take on larger problems, and this section lists afew of the issues that must be resolved if TM is toachieve this lofty goal.Of course, everyone involved should treat this asa learning experience. It would seem that TM researchershave great deal to learn from practitionerswho have successfully built large software systemsusing traditional synchronization primitives.And vice versa.15.2 Shared-Memory ParallelFunctional Programming15.3 Process-Based ParallelFunctional Programming2. Another interesting property of TM, noted byShpeisman et al. [SATG + 09], is that TM intertwinesthe synchronization with the data itprotects. This property underlies TM’s issueswith I/O, memory-mapping operations, extratransactionalaccesses, and debugging breakpoints.In contrast, conventional synchronizationprimitives, including locking and RCU,maintain a clear separation between the synchronizationprimitives and the data that theyprotect.3. One of the stated goals of many workers in theTM area is to ease parallelization of large sequentialprograms. As such, individual transactionsare commonly expected to execute se-4 Kudos to the TxLinux group, Maged Michael, and JoshTriplett for coming up with a number of the above alternatives.