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

144 CHAPTER 15. CONFLICTING VISIONS OF THE FUTUREitdifficulttoincludegeneralI/Ooperationsintransactions.Here are some options for handling of I/O withintransactions:1. RestrictI/OwithintransactionstobufferedI/Owith in-memory buffers. These buffers maythen be included in the transaction in the sameway that any other memory location might beincluded. This seems to be the mechanism ofchoice, and it does work well in many commoncasesofsituationssuchasstreamI/OandmassstorageI/O. However, special handling is requiredin cases where multiple record-orientedoutput streams are merged onto a single filefrom multiple processes, as might be done usingthe “a+” option to fopen() or the O_APPENDflag to open(). In addition, as will be seenin the next section, common networking operationscannot be handled via buffering.2. Prohibit I/O within transactions, so that anyattempt to execute an I/O operation abortsthe enclosing transaction (and perhaps multiplenested transactions). This approach seemsto be the conventional TM approach for unbufferedI/O, but requires that TM interoperatewith other synchronization primitives thatdo tolerate I/O.3. Prohibit I/O within transactions, but enlist thecompiler’s aid in enforcing this prohibition.4. Permit only one special “inevitable” transaction[SMS08] to proceed at any given time,thus allowing inevitable transactions to containI/O operations. This works in general,but severely limits the scalability and performanceof I/O operations. Given that scalabilityand performance is a first-class goal of parallelism,this approach’s generality seems a bitself-limiting. Worse yet, use of inevitability totolerate I/O operations seems to prohibit use ofmanual transaction-abort operations. 15. Create new hardware and protocols such thatI/O operations can be pulled into the transactionalsubstrate.Inthecaseofinputoperations,the hardware would need to correctly predictthe result of the operation, and to abort thetransaction if the prediction failed.I/O operations are a well-known weakness of TM,and it is not clear that the problem of supporting1 This difficulty was pointed out by Michael Factor.I/O in transactions has a reasonable general solution,at least if “reasonable” is to include usableperformance and scalability. Nevertheless, continuedtime and attention to this problem will likelyproduce additional progress.15.1.2 RPC OperationsOne can execute RPCs within a lock-based criticalsection, as well as from within an RCU read-sidecritical section. What happens when you attemptto execute an RPC from within a transaction?If both the RPC request and its response are to becontained within the transaction, and if some partof the transaction depends on the result returnedby the response, then it is not possible to use thememory-buffer tricks that can be used in the caseof buffered I/O. Any attempt to take this bufferingapproach would deadlock the transaction, as therequest could not be transmitted until the transactionwas guaranteed to succeed, but the transaction’ssuccess might not be knowable until after theresponse is received, as is the case in the followingexample:1 begin_trans();2 rpc_request();3 i = rpc_response();4 a[i]++;5 end_trans();The transaction’s memory footprint cannot be determineduntil after the RPC response is received,and until the transaction’s memory footprint can bedetermined, it is impossible to determine whetherthe transaction can be allowed to commit. Theonly action consistent with transactional semanticsisthereforetounconditionallyabortthetransaction,which is, to say the least, unhelpful.Here are some options available to TM:1. Prohibit RPC within transactions, so that anyattempt to execute an RPC operation abortsthe enclosing transaction (and perhaps multiplenested transactions). Alternatively, enlist thecompilertoenforceRPC-freetransactions. Thisapproach does works, but will require TM tointeract with other synchronization primitives.2. Permit only one special “inevitable” transaction[SMS08] to proceed at any given time,thus allowing inevitable transactions to containRPC operations. This works in general,but severely limits the scalability and performanceof RPC operations. Given that scalabilityand performance is a first-class goal of