10.07.2015 Views

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

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

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

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

15.1. TRANSACTIONAL MEMORY 145parallelism, this approach’s generality seems abit self-limiting. Furthermore, use of inevitabletransactions to permit RPC operations rulesout manual transaction-abort operations oncethe RPC operation has started.3. Identify special cases where the success of thetransaction may be determined before the RPCresponse is received, and automatically convertthesetoinevitabletransactionsimmediatelybeforesending the RPC request. Of course, if severalconcurrent transactions attempt RPC callsin this manner, it might be necessary to roll allbut one of them back, with consequent degradationof performance and scalability. Thisapproach nevertheless might be valuable givenlong-running transactions ending with an RPC.This approach still has problems with manualtransaction-abort operations.4. Identify special cases where the RPC responsemay be moved out of the transaction, and thenproceed using techniques similar to those usedfor buffered I/O.5. Extend the transactional substrate to includethe RPC server as well as its client. This is intheory possible, as has been demonstrated bydistributed databases. However, it is unclearwhether the requisite performance and scalabilityrequirements can be met by distributeddatabasetechniques, given that memory-basedTM cannot hide such latencies behind those ofslow disk drives. Of course, given the adventof solid-state disks, it is also unclear how muchlonger databases will be permitted to hide theirlatencies behind those of disks drives.As noted in the prior section, I/O is a knownweakness of TM, and RPC is simply an especiallyproblematic case of I/O.15.1.3 Memory-Mapping Operations<strong>It</strong> is perfectly legal to execute memory-mappingoperations (including mmap(), shmat(), andmunmap() [Gro01]) within a lock-based criticalsection, and, at least in principle, from within anRCU read-side critical section. <strong>What</strong> happens whenyou attempt to execute such an operation fromwithin a transaction? More to the point, whathappens if the memory region being remappedcontains some variables participating in the currentthread’s transaction? <strong>And</strong> what if this memoryregion contains variables participating in some otherthread’s transaction?<strong>It</strong> should not be necessary to consider cases wherethe TM system’s metadata is remapped, given thatmost locking primitives do not define the outcomeof remapping their lock variables.Here are some memory-mapping options availableto TM:1. Memory remapping is illegal within a transaction,and will result in all enclosing transactionsbeing aborted. This does simplify things somewhat,but also requires that TM interoperatewithsynchronizationprimitivesthatdotolerateremapping from within their critical sections.2. Memory remapping is illegal within a transaction,and the compiler is enlisted to enforce thisprohibition.3. Memory mapping is legal within a transaction,but aborts all other transactions having variablesin the region mapped over.4. Memory mapping is legal within a transaction,but the mapping operation will fail if the regionbeing mapped overlaps with the current transaction’sfootprint.5. All memory-mapping operations, whetherwithinoroutsideatransaction, checktheregionbeing mapped against the memory footprint ofall transactions in the system. <strong>If</strong> there is overlap,then the memory-mapping operation fails.6. The effect of memory-mapping operations thatoverlapthememoryfootprintofanytransactionin the system is determined by the TM conflictmanager, which might dynamically determinewhether to fail the memory-mapping operationor abort any conflicting transactions.In is interesting to note that munmap() leaves therelevant region of memory unmapped, which couldhave additional interesting implications. 215.1.4 Multithreaded Transactions<strong>It</strong> is perfectly legal to create processes and threadswhile holding a lock or, for that matter, from withinan RCU read-side critical section. Not only is itlegal, but it is quite simple, as can be seen from thefollowing code fragment:2 This difference between mapping and unmapping wasnoted by Josh Triplett.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!