Design tradeoffs in modern software transactional memory systems

Marathe, Virendra J.; Scherer, William N.; Scott, Michael L.

doi:10.1145/1066650.1066660

Cited by 68 publications

(41 citation statements)

References 17 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…In [61], Marathe et al compared two software transactional memory implementations, i.e., DSTM [48] and OSTM [32]. They show that, depending on the benchmark, each of the systems has the potential to outperform the other.…”

Section: Adaptive Software Transactional Memory Astmmentioning

confidence: 99%

See 1 more Smart Citation

Transactional memory

Grahn¹

2010

Journal of Parallel and Distributed Computing

View full text Add to dashboard Cite

Current and future processor generations are based on multicore architectures where the performance increase comes from an increasing number of cores on a chip. In order to utilize the performance potential of multicore architectures the programs also need to be parallel, but writing parallel programs is a non-trivial task. Transactional memory tries to ease parallel program development by providing atomic and isolated execution of code sequences, enabling software composability and protected access to shared data. In addition, transactional memory has the ability to execute atomic code sequences in parallel as long as no data conflicts occur. Transactional memory implementation proposals exist for both hardware and software, as well as hybrid solutions. This special issue on transactional memory introduces transactional memory as a concept, presents an overview of some of the most important approaches so far, and finally, includes five articles that advances the state-of-the-art in transactional memory research.

show abstract

Section: Adaptive Software Transactional Memory Astmmentioning

confidence: 99%

“…Adaptive Software Transactional Memory (ASTM) [62] is based on their observations in [61]. ASTM implements both early and late conflict detection, and can adaptively switch between the two depending on the workload characteristics.…”

Section: Adaptive Software Transactional Memory Astmmentioning

confidence: 99%

Transactional memory

Grahn¹

2010

Journal of Parallel and Distributed Computing

View full text Add to dashboard Cite

show abstract

“…In previous work, we reviewed several STM systems [16,18] and ultimately designed both ASTM [17] and RSTM [19] to decrease overhead on the critical path of transactions. In ASTM, we adaptively switch from DSTM-style eager acquire [11] to OSTMstyle lazy acquire [2,3].…”

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

Self Cite

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

“…Unfortunately, while excellent nonblocking implementations exist for many important data structures (only a few of which we have room to cite here [21,23,24,29,30]), general-purpose mechanisms remain elusive. Several groups (including our own) are working on this topic [6,10,18,26], but it still seems unlikely that nonblocking synchronization will displace locks entirely soon.…”

Section: Related Workmentioning

confidence: 99%

Preemption Adaptivity in Time-Published Queue-Based Spin Locks

Scherer

Scott

2005

Lecture Notes in Computer Science

Self Cite

View full text Add to dashboard Cite

The proliferation of multiprocessor servers and multithreaded applications has increased the demand for high-performance synchronization. Traditional scheduler-based locks incur the overhead of a full context switch between threads and are thus unacceptably slow for many applications. Spin locks offer low overhead, but they either scale poorly on large-scale SMPs (test-and-set style locks) or behave poorly in the presence of preemption (queue-based locks).Previous work has shown how to build preemption-tolerant locks using an extended kernel interface, but such locks are neither portable to nor even compatible with most operating systems.In this work, we propose a time-publishing heuristic in which each thread periodically records its current timestamp to a shared memory location. Given the high resolution, roughly synchronized clocks of modern processors, this convention allows threads to guess accurately which peers are active based on the currency of their timestamps. We implement two queuebased locks, MCS-TP and CLH-TP, and evaluate their performance relative to both traditional spin locks and preemption-safe locks on a 32-processor IBM p690 multiprocessor. Experimental results indicate that time-published locks make it feasible, for the first time, to use queue-based spin locks on multiprogrammed systems with a standard kernel interface.

show abstract

Design tradeoffs in modern software transactional memory systems

Cited by 68 publications

References 17 publications

Transactional memory

Transactional memory

Conflict Detection and Validation Strategies for Software Transactional Memory

Preemption Adaptivity in Time-Published Queue-Based Spin Locks

Contact Info

Product

Resources

About