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.
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
References:
Archives