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

15.1. TRANSACTIONAL MEMORY 147It appears that transactions were conceived asstanding alone, with no interaction required withany other synchronization mechanism. If so, it is nosurprise that much confusion and complexity ariseswhencombiningtransactionswithnon-transactionalaccesses. But unless transactions are to be confinedto small updates to isolated data structures, or alternativelyto be confined to new programs that donot interact with the huge body of existing parallelcode, then transactions absolutely must be so combinedif they are to have large-scale practical impactin the near term.15.1.6 Time DelaysAn important special case of interaction with extratransactionalaccesses involves explicit time delayswithin a transaction. Of course, the idea of a timedelay within a transaction flies in the face of TM’satomicity property, but one can argue that this sortof thing is what weak atomicity is all about. Furthermore,correct interaction with memory-mappedI/O sometimes requires carefully controlled timing,andapplicationsoftenusetimedelaysforvariedpurposes.So, what can TM do about time delays withintransactions?1. Ignore time delays within transactions. Thishas an appearance of elegance, but like toomany other “elegant” solutions, fails to survivefirstcontactwithlegacycode. Suchcode, whichmight well have important time delays in criticalsections, would fail upon being transactionalized.2. Abort transactions upon encountering a timedelayoperation. This is attractive, but it is unfortunatelynotalwayspossibletoautomaticallydetect atime-delay operation. Isthattight loopcomputingsomethingimportant, orisitinsteadwaiting for time to elapse?3. Enlist the compiler to prohibit time delayswithin transactions.4. Let the time delays execute normally. Unfortunately,some TM implementations publish modificationsonly at commit time, which would inmanycasesdefeatthepurposeofthetimedelay.It is not clear that there is a single correct answer.TM implementations featuring weak atomicity thatpublish changes immediately within the transaction(rolling these changes back upon abort) might bereasonably well served by the last alternative. Evenin this case, the code at the other end of the transactionmay require a substantial redesign to tolerateaborted transactions.15.1.7 LockingIt is commonplace to acquire locks while holdingother locks, which works quite well, at least as longas the usual well-known software-engineering techniquesare employed to avoid deadlock. It is notunusual to acquire locks from within RCU read-sidecritical sections, which eases deadlock concerns becauseRCU read-side primitives cannot participatedin lock-based deadlock cycles. But happens whenyou attempt to acquire a lock from within a transaction?In theory, the answer is trivial: simply manipulatethe data structure representing the lock as partof the transaction, and everything works out perfectly.In practice, a number of non-obvious complications[VGS08] can arise, depending on implementationdetails of the TM system. These complicationscan be resolved, but at the cost of a 45overheadfor locks acquired outside of transactions anda 300in overhead for locks acquired within transactions.Although these overheads might be acceptablefortransactionalprogramscontainingsmallamounts of locking, they are often completely unacceptablefor production-quality lock-based programswishing to use the occasional transaction.1. Use only locking-friendly TM implementations.Unfortunately, the locking-unfriendly implementationshave some attractive properties, includinglow overhead for successful transactionsand the ability to accommodate extremely largetransactions.2. Use TM only “in the small” when introducingTM to lock-based programs, thereby accommodatingthe limitations of locking-friendly TMimplementations.3. Set aside locking-based legacy systems entirely,re-implementing everything in terms of transactions.This approach has no shortage of advocates,but this requires that all the issues describedin this series be resolved. During thetime it takes to resolve these issues, competingsynchronization mechanisms will of course alsohave the opportunity to improve.4. Use TM strictly as an optimization inlock-based systems, as was done by theTxLinux [RHP + 07] group. This approach