Software transactional memory

We present Selective Multi-Versioning (SMV), a new STM that reduces the number of aborts, especially those of long read-only transactions. SMV keeps old object versions as long as they might be useful for some transaction to read. It is able to do so while still allowing reading transactions to be invisible by relying on automatic garbage collection to dispose of obsolete versions.SMV is most suitable for read-dominated workloads, for which it achieves much better performance than previous solutions. It has an up to ×11 throughput improvement over a single-version STM and more than a two-fold improvement over an STM keeping a constant number of versions per object. We show that unlike STMs keeping a constant number of versions, SMV operates successfully even in systems with limited memory.

show abstract

“…Commit (lines [15][16][17][18][19][20][21][22][23][24][25][26][27][28] consists of the following steps:…”

Section: : Upon Startupmentioning

confidence: 99%

“…Transactional memory [16,28] is an increasingly popular paradigm for concurrent computing in multi-core architectures. Most transactional memory implementations today are software toolkits, or STMs for short.…”

Section: Introductionmentioning

confidence: 99%

SMV: Selective Multi-Versioning STM

Perelman

Byshevsky

Litmanovich

et al. 2011

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…The C# STM uses aggressive compiler optimization to reduce overheads, while the Haskell TM focuses on rich semantics for composability. Like previous word-based STMs [2,8,26], these systems avoid the cost of copying unmodified portions of objects, but incur bookkeeping costs on every load and store (or at least on every one that the compiler cannot prove is redundant). These differences complicate direct comparisons between word-based and object-based STM systems.…”

Section: Related Workmentioning

confidence: 99%

Conflict Detection and Validation Strategies for Software Transactional Memory

Spear

Marathe

Scherer

et al. 2006

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. In a software transactional memory (STM) system, conflict detection is the problem of determining when two transactions cannot both safely commit. Validation is the related problem of ensuring that a transaction never views inconsistent data, which might potentially cause a doomed transaction to exhibit irreversible, externally visible side effects. Existing mechanisms for conflict detection vary greatly in their degree of speculation and their relative treatment of read-write and write-write conflicts. Validation, for its part, appears to be a dominant factor-perhaps the dominant factor-in the cost of complex transactions.We present the most comprehensive study to date of conflict detection strategies, characterizing the tradeoffs among them and identifying the ones that perform the best for various types of workload. In the process we introduce a lightweight heuristic mechanism-the global commit counter-that can greatly reduce the cost of validation and of single-threaded execution. The heuristic also allows us to experiment with mixed invalidation, a more opportunistic interleaving of reading and writing transactions. Experimental results on a 16-processor SunFire machine running our RSTM system indicate that the choice of conflict detection strategy can have a dramatic impact on performance, and that the best choice is workload dependent. In workloads whose transactions rarely conflict, the commit counter does little to help (and can even hurt) performance. For less scalable applications, however-those in which STM performance has traditionally been most problematic-it can improve transaction throughput many fold.

show abstract

“…Lock-free data structures [35,28] and transactional memory [26,38] are also closely related to transactional monitors. Herlihy et al [25] present a solution closest in spirit to transactional monitors.…”

Section: Related Workmentioning

confidence: 99%

Transactional Monitors for Concurrent Objects

Welc

Jagannathan

Hosking

2004

ECOOP 2004 – Object-Oriented Programming

View full text Add to dashboard Cite

Abstract. Transactional monitors are proposed as an alternative to monitors based on mutual-exclusion synchronization for object-oriented programming languages. Transactional monitors have execution semantics similar to mutualexclusion monitors but implement monitors as lightweight transactions that can be executed concurrently (or in parallel on multiprocessors). They alleviate many of the constraints that inhibit construction of transparently scalable and robust applications. We undertake a detailed study of alternative implementation schemes for transactional monitors. These different schemes are tailored to different concurrent access patterns, and permit a given application to use potentially different implementations in different contexts. We also examine the performance and scalability of these alternative approaches in the context of the Jikes Research Virtual Machine, a state-of-the-art Java implementation. We show that transactional monitors are competitive with mutualexclusion synchronization and can outperform lock-based approaches up to five times on a wide range of workloads.

show abstract

Software transactional memory

Abstract: As we learn from the literature,

Cited by 917 publications

References 25 publications

SMV: Selective Multi-Versioning STM

SMV: Selective Multi-Versioning STM

Conflict Detection and Validation Strategies for Software Transactional Memory

Transactional Monitors for Concurrent Objects

Contact Info

Product

Resources

About