events. Long transactions may be rare,
but they still must execute in a manner
that preserves atomicity and isolation.
Placing implementation-dependent
limits on transaction sizes is unacceptable from a programmer’s perspective.
A simple mechanism to handle cache
overflows or system events is to ensure
the offending transaction executes to
completion. 21 When one of these events
occurs, the HTM system can update
memory directly without tracking the
read set, write set, or old data versions.
At this point, however, no other transactions can execute, as conflict detection
is no longer possible. Moreover, direct
memory updates without undo logging
preclude the use of explicit abort or retry statements in a transaction.
Rajwar et al. proposed Virtualized
TM (VTM), an alternative approach
that maintains atomicity and isolation
for even if a transaction is interrupted
by a cache overflow or a system event. 25
VTM maps the key bookkeeping data
structures for transactional execution
(read set, write set, write buffer or un-do-log) to virtual memory, which is effectively unbounded and is unaffected
by system interruptions. The hardware
caches hold the working set of these
data structures. VTM also suggested
the use of hardware signatures to avoid
redundant searches through structures
in virtual memory.
ILLUS TRATION BY STUDIO TONNE / ZEEGENRUSH.COM
A final technique to address the
limitation of hardware resources is to
use a hybrid HTM–STM system. 7, 17 A
transaction starts in the HTM mode using hardware mechanisms for conflict
detection and data versioning. If HTM
resources are exceeded, the transaction is rolled back and restarted in the
STM mode with additional instrumentation. This approach requires two versions of each function, but it provides
good performance for short transactions. A challenge for hybrid systems is
to detect conflict between concurrently
HTM and STM transactions.
Hardware/Software Interface for
Transactional Memory. Hardware designs are optimized to make the common case fast and reduce the cost of
correctly handling rare events. Processor vendors will follow this principle
in introducing hardware support for
transactional execution. Initial systems
are likely to devote modest hardware
resources to TM. As more applications
review articles
use transactions, more aggressive hardware designs, including full-featured
HTM systems, may become available.
Regardless of the amount of hardware used for TM, it is important that
HTM systems provide functionality
that is useful in developing practical
programming models and execution
environments. A significant amount
of HTM research has focused on hardware/software interfaces that can support rich software features. McDonald
et al. suggested four interface mechanisms for HTM systems. 20 The first
mechanism is a two-phase commit
protocol that architecturally separates
transaction validation from commit-
ting its updates to memory. The second mechanism is transactional handlers that allow software to interface
on significant events such as conflict
detection, commit, or abort. Shriraman et al. suggest alert-on-update,
a similar mechanism that invokes a
software handler when HTM hardware detects conflicts or experiences
overflows. 31 The third mechanism is
support for closed and open-nested
transactions. Open nesting allows software to interrupt the currently executing transaction and run some service
code (for example, a system call) with
independent atomicity and isolation
guarantees. Other researchers suggest it is sufficient to suspend HTM
transactions to service system calls
and I/O operations. 24, 32 Nevertheless,
if the service code uses transactions to
access shared data in memory, the requirements of transaction pausing are
not significantly different from those
of open-nested transactions. Finally,
both McDonald et al. and Sriraman et
al. propose multiple types of load and
store instructions what allow compilers to distinguish accesses to thread-private, immutable, or idempotent
data from accesses to truly shared data.
By providing such mechanisms, HTM
systems can support software features
ranging from conditional synchronization and limited I/O within transactions5, 32 to high-level concurrency
models that avoid transaction aborts
on memory conflicts if the application-level semantics are not violated. 4
open issues
Beyond the implementation issues
discussed here, TM faces a number of
challenges that are the subject of active
research. One serious difficulty with
optimistic TM is that a transaction that
executed an I/O operation may roll back
at a conflict. I/O in this case consists of
any interaction with the world outside
of the control of the TM system. If a
transaction aborts, its I/O operations
should roll back as well, which may be
difficult or impossible to accomplish
in general. Buffering the data read or
written by a transaction permits some
rollbacks, but buffering fails in simple
situations, such as a transaction that
writes a prompt and then waits for user
input. A more general approach is to
designate a single privileged transaction that runs to completion, by ensuring it triumphs over all conflicting
transactions. Only the privileged transaction can perform I/O (but the privilege can be passed between transactions), which unfortunately limits the
amount of I/O a program can perform.
Another major issue is strong and
weak atomicity. STM systems generally
implement weak atomicity, in which
non-transactional code is not isolated
from code in transactions. HTM systems, on the other hand, implement
strong atomicity, which provides a
more deterministic programming
model in which non-transactional code
does not affect the atomicity of a transaction. This difference presents several
problems. Beyond the basic question of
which model is a better basis for writing software, the semantic differences
makes it difficult to develop software
that runs on both types of systems.