Safe Open-Nested Transactions Through Ownership
Kunal Agrawal I-Ting Angelina Lee Jim Sukha
MIT Computer Science and Artificial Intelligence Laboratory
Cambridge, MA 02139, USA
ABSTRACT
Researchers in transactional memory (TM) have proposed open nesting as a methodology for increasing the
concurrency of a program. The idea is to ignore certain “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 nested transaction represents. To support this methodology, TM
systems use an open-nested commit mechanism that commits 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, an unconstrained use of open-nested commits can lead to
anomalous program behavior.
In this paper, we describe a 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 open-nested and closed-nested commit which commits a piece of data differently depending
on whether the current Xmodule owns the data or not. Moreover, we give a set of precise constraints on
interactions and sharing of data among the Xmodules based on familiar notions of abstraction. We prove that
ownership-aware TM has has clean memory-level semantics and can guarantee serializability by modules,
which is an adaptation of multilevel serializability from databases to TM. 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, the OAT model is free from semantic deadlock.
1. INTRODUCTION
In the past few years, transactional memory [4] has been an active field of research. Transactional memory
(TM) is meant to simplify concurrency control in parallel programming by providing a transactional interface
for accessing memory; the programmer simply encloses the critical region inside an atomic block, and
the TM system ensures that that section of code executes atomically. A TM system enforces atomicity by
tracking the memory locations that each transaction in the system accesses, finding transaction conflicts,
This research is supported in part by NSF Grants CNS-0615215 and CNS-0540248 and a grant from Intel corporation.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
Copyright c© ACM [to be supplied]. . . $5.00.

and aborting and possibly retrying transactions that conflict. TM guarantees that transactions are serializable
[10], 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 of the issues that programmers must deal with is the semantics of nested trans-
actions. When a TM system has closed-nested transactions [6], if a transaction X contains a closed-nested
transaction Y , after Y commits, for the purpose of detecting conflicts the TM runtime considers any memory
locations accessed by Y as conceptually also being accessed by X . TM with closed-nested transactions guar-
antees that transactions are serializable at the level of memory. Researchers have observed, however, that
closed nesting might unnecessarily restrict concurrency in transactional programs because it does not allow
two “high-level” transactions to ignore conflicts due to accesses to shared “low-level” memory inside nested
transactions.
To increase concurrency in transactional programs, researchers have proposed the methodology of open-
nested transactions. The open-nesting methodology incorporates the open-nested commit mechanism [5,8].
Conceptually, when an open-nested transaction Y (nested inside transaction X ) commits, Y makes its changes
directly to memory instead of propagating the changes to its parent X . Thus, the TM runtime 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 ; therefore 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, with open nesting, if X aborts, it may need to execute compensating actions to undo
the effect of its committed open-nested transactions Y . Moss in [7] illustrates use of open nesting with an
application that uses a B-tree. In [9], Ni et. al 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 [1]
that can be tricky to reason about. Since programmers must understand the open-nested commit mechanism
to program using open nesting, at first glance, it might seem that using the open-nesting methodology
is complicated. Although researchers have demonstrated specific examples that safely use an open-nested
commit mechanism, 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. Moreover,
since these working 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.
We believe that one reason for the apparent complexity of open nesting is that the mechanism and
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 ℓ1, but does
care about ℓ2. The TM system can not distinguish between these two accesses, and will commit both in an
open-nested manner, leading to anomalous behavior. In fact, specific uses of open nesting that researchers
describe [3, 9] work because they exhibit a clean separation of the data accessed by an outer transaction
and its (nested) inner transaction. For instance, in the TCC examples [3], the open-nested transactions are
operations on a data structure, and the data structure “owns” memory needed for its implementation that can
not be accessed by a user’s application.
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 such an ownership-aware TM system allows programmers safely use the methodology
of open nesting because the runtime’s behavior more closely reflects the programmer’s intent, and because