The overhead posed by STM may likely overshadow its promise.
TM (transactional memory) 1 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-grain locking, while avoiding common pitfalls of lock composition such as deadlock. In this article we explore the performance of a highly optimized STM and observe that the overall performance of TM is significantly 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 Rajwar2 present an overview of design tradeoffs for implementations of transactional memory systems. Here are some of the design choices: • STM (software-only TM) 3, 4, 5, 6, 7, 8, 9 is the focus of this article. While offering flexibility and no hardware cost, it leads to overhead in excess of most users’ tolerance. • HTM (hardware-only TM) 10, 11, 12, 13, 14, 15, 16 suffers from two major impediments: high implementation and verification costs lead to design risks too large to justify on a niche programming model; and hardware capacity constraints lead to significant performance
References:
Archives