Safe open-nested transactions through ownership

Kunal Agrawal, I-Ting Angelina Lee, Jim Sukha
2008 Proceedings of the 14th ACM SIGPLAN symposium on Principles and practice of parallel programming - PPoPP '09  
Researchers in transactional memory (TM) have proposed open nesting as a methodology for increasing the concurrency of transactional programs. The idea is to ignore "low-level" memory operations of an open-nested transaction when detecting conflicts for its parent transaction, and instead perform abstract concurrency control for the "high-level" operation that the nested transaction represents. To support this methodology, TM systems use an open-nested commit mechanism that commits all changes
more » ... ommits all changes performed by an open-nested transaction directly to memory, thereby avoiding low-level conflicts. Unfortunately, because the TM runtime is unaware of the different levels of memory, unconstrained use of open-nested commits can lead to anomalous program behavior. We describe the framework of ownership-aware transactional memory which incorporates the notion of modules into the TM system and requires that transactions and data be associated with specific transactional modules or Xmodules. We propose a new ownership-aware commit mechanism, a hybrid between an opennested and closed-nested commit which commits a piece of data differently depending on which Xmodule owns the data. Moreover, we provide a set of precise constraints on interactions and sharing of data among the Xmodules based on familiar notions of abstraction. The ownership-aware commit mechanism and these restrictions on Xmodules allow us to prove that ownership-aware TM has clean memory-level semantics. In particular, it guarantees serializability by modules, an adaptation of the definition of multilevel serializability from database systems. In addition, we describe how a programmer can specify Xmodules and ownership in a Java-like language. Our type system can enforce most of the constraints required by ownership-aware TM statically, and can enforce the remaining constraints dynamically. Finally, we prove that if transactions in the process of aborting obey restrictions on their memory footprint, then ownership-aware TM is free from semantic deadlock. ACM [to be supplied]. and write sets), finding transaction conflicts, and aborting transactions that conflict. TM guarantees that transactions are serializable [12] ; that is, transactions affect global memory as if they were executed one at a time in some order, even if in reality, several executed concurrently. When using TM, one issue that programmers must deal with is the semantics of nested transactions. If a transaction Y is closed nested [8] inside transaction X , for the purpose of detecting conflicts, the TM system considers any memory locations accessed by Y as conceptually also being accessed by its parent X . Thus, upon Y 's commit, the TM system merges Y 's read and write sets into the read and write sets of X . TM with closed-nested transactions guarantees that transactions are serializable at the level of memory. Researchers have observed, however, that closed nesting might unnecessarily restrict concurrency in programs because it does not allow two "high-level" transactions to ignore conflicts due to accesses to shared "low-level" memory done by nested transactions. Researchers have proposed the methodology of open-nested transactions to increase concurrency in transactional programs by carefully breaking serializability at the memory level. The open-nesting methodology incorporates the open-nested commit mechanism [7, 10] . When an open-nested transaction Y (nested inside transaction X ) commits, Y 's changes are committed to memory and Y 's read and write sets are discarded. Thus, the TM system no longer detects conflicts with X due to memory accessed by Y . In this methodology, the programmer considers Y 's internal memory operations to be at a "lower level" than X ; thus X should not care about the memory accessed by Y when checking for conflicts. Instead, Y must acquire an abstract lock based on the high-level operation that Y represents and propagate this lock to X , so that the TM system can perform concurrency control at an abstract level. Also, if X aborts, it may need to execute compensating actions to undo the effect of its committed open-nested subtransaction Y . Moss in [9] illustrates use of open nesting with an application that uses a B-tree. Ni et al. [11] describe a software TM system that supports the open-nesting methodology. An unconstrained use of the open-nested commit mechanism can lead to anomalous program behavior that can be tricky to reason about [2]. We believe that one reason for the apparent complexity of open nesting is that the mechanism and the methodology make different assumptions about memory. Consider a transaction Y open nested inside transaction X . The open-nesting methodology requires that X ignore the "lower-level" memory conflicts generated by Y , while the open-nested commit mechanism will ignore all the memory operations inside Y . Say Y accesses two memory locations ℓ 1 and ℓ 2 , and X does not care about changes made to ℓ 2 , but does care about ℓ 1 . The TM system can not distinguish between these two accesses, and will commit both in an open-nested manner, leading to anomalous behavior. Researchers have demonstrated specific examples [4, 11] that safely use an open-nested commit mechanism. These examples work, however, because the inner (open) transactions never write to any data that is accessed by the outer transactions. Moreover, since these examples require only two levels of nesting, it is not obvious how one can correctly use open-nested commits in a program with more than two levels of abstraction. The literature on TM offers relatively little in the way of formal programming guidelines which one can follow to have provable guarantees of safety when using open-nested commits. Contributions In this paper, we bridge the gap between memory-level mechanisms for open nesting and the high-level view by explicitly integrating the notions of transactional modules (Xmodules) and ownership into the TM system. We believe the ownership-aware TM system allows the programmer to safely use the methodology of open nesting, because the runtime's behavior more closely reflects the programmer's intent. In addition, the structure imposed by ownership allows a language and runtime to enforce properties needed to provide provable guarantees of "safety" to the programmer. More specifically, the contributions of this paper are as follows:
doi:10.1145/1504176.1504200 dblp:conf/ppopp/AgrawalLS09 fatcat:x4th2lw74bh5xnm4uxjdpleksi