practice
Doi: 10.1145/1400214.1400228
and observe the overall performance of
TM is much worse at low levels of parallelism, which is likely to limit the adoption of this programming paradigm.
Different implementations of
transactional memory systems make
tradeoffs that impact both performance
and programmability. Larus and Rajwar16 present an overview of design
trade-offs for implementations of trans-
software actional memory systems. We summarize some of the design choices here:
˲ Software-only (STM) 7, 10, 12, 14, 18, 23, 25 is
the focus here. While offering flexibility
transactional and no hardware cost, it leads to overhead in excess of most users’ tolerance.
˲ Hardware-only (HTM) 2, 4, 9, 13, 19, 20, 35
suffers from two major impediments:
memory: Why high implementation and verification
costs lead to design risks too large to
justify on a niche programming model;
hardware capacity constraints lead to
is it only a significant performance degradation
when overflow occurs, and proposals for
managing overflows (for example, signatures5) incur false positives that add
Research toy? complexity to the programming model.
Therefore, from an industrial perspective, HTM designs have to provide more
benefits for the cost, on a more diverse
set of workloads (with varying transactional characteristics) for hardware designers to consider implementation.a
˲ Hybrid1, 6, 24, 28 is the most likely platform for the eventual adoption of TM
by a wide audience, although the exact
mix of hardware and software support
remains unclear.
A special case of the hybrid systems
are hardware-accelerated STMs. In this
scenario, the transactional semantics
are provided by the STM, and hardware
primitives are only used to speed up
critical performance bottlenecks in the
STM. Such systems could offer an attractive solution if the cost of hardware
primitives is modest and may be further
amortized by other uses in the system.
Independent of these implementa-
The promise of STM may likely be undermined
by its overheads and workload applicabilities.
BY căLin cas˛caVaL, coLin BLunDeLL, maGeD michaeL,
haRoLD W. cain, PenG Wu, stefanie chiRas,
anD siDDhaRtha chatteRJee
trAnsActionAL MEMor Y (TM) 13 is a concurrency
control paradigm that provides atomic and isolated
execution for regions of code. TM is considered by
many researchers to be one of the most promising
solutions to address the problem of programming
multicore processors. Its most appealing feature is
that most programmers only need to reason locally
about shared data accesses, mark the code region to
be executed transactionally, and let the underlying
system ensure the correct concurrent execution. This
model promises to provide the scalability of fine-grained locking while avoiding common pitfalls of
lock composition such as deadlock. In this article, we
explore the performance of a highly optimized STM
a Reuse of hardware for other purposes can also
justify its inclusion, as the case may be for
Sun’s implementation of Scout Threading in
the Rock processor. 32
