Kicking the tires of software transactional memory

Yoo, Richard M.; Ni, Yang; Welc, Adam; Saha, Badal C.; Adl-Tabatabai, Ali-Reza; Lee, Hsien-Hsin S.

doi:10.1145/1378533.1378582

Cited by 80 publications

(57 citation statements)

References 22 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…A similar technique is already known to significantly impact performance of STM in certain cases [25], which our experiments confirm.…”

Section: Stm-mt Performancesupporting

confidence: 82%

“…The compiler generates code that invokes appropriate STM read/write calls. While an STM compiler significantly reduces programming complexity, it can degrade performance of resulting programs (when compared to manual instrumentation) due to overinstrumentation [3,8,25]: basically, the compiler instruments the code conservatively with unnecessary calls to STM functions, as it cannot precisely determine which instructions indeed access shared data.…”

Section: Compiler Over-instrumentationmentioning

confidence: 99%

“…Two approaches to prevent these have been considered: (1) a programmer explicitly marks transactions that privatize data, or (2) the STM transparently ensures that all transactions safely privatize data. Explicit privatization places additional burden on the programmer, while transparent privatization incurs runtime overheads [25], especially in cases when no data is actually being privatized.…”

Section: Modelmentioning

confidence: 99%

“…Compiler instrumentation often replaces more memory references by STM load and store calls than strictly necessary, resulting in the reduced performance of generated code (this is known as over-instrumentation [3,8,25]). Ideally, the compiler would only replace memory accesses with STM calls when they reference some shared data.…”

Section: Stm-ce Performancementioning

confidence: 99%

See 3 more Smart Citations

Why STM can be more than a research toy

et al. 2011

View full text Add to dashboard Cite

Software Transactional Memory (STM) promises to simplify concurrent programming without requiring specific hardware support. Yet, STM's credibility lies on the extent to which it enables to leverage multicores and outperform sequential code. A recent CACM paper [3] questioned this ability and suggested the confinement of STM to a research toy.We revisit these conclusions through the most to date extensive comparison of STM performance to sequential code. We evaluate a state-of-the-art STM system, SwissTM, on a wide range of benchmarks and two different multicore systems. We dissect the inherent costs of synchronization as well as the overheads of compiler instrumentation and transparent privatization.Our results show that an STM with manually instrumented benchmarks and explicit privatization outperforms sequential code by up to 29 times on SPARC with 64 concurrent threads and by up to 9 times on x86 with 16 concurrent threads. Indeed the overheads of compiler instrumentation and transparent privatization are substantial, yet they do not prevent STM from generally outperforming sequential code.

show abstract

“…A similar technique is already known to significantly impact performance of STM in certain cases [25], which our experiments confirm.…”

Section: Stm-mt Performancesupporting

confidence: 82%

Section: Compiler Over-instrumentationmentioning

confidence: 99%

Section: Modelmentioning

confidence: 99%

Section: Stm-ce Performancementioning

confidence: 99%

See 2 more Smart Citations

Why STM can be more than a research toy

et al. 2011

View full text Add to dashboard Cite

show abstract

“…Existing STMs are impractical because they add high overhead-making it hard to achieve good performance even if STM scales well-and also often provide weak guarantees. These drawbacks have led some researchers to question the viability of STM and call it a "research toy" [11,20,59]. This paper introduces a novel STM called LarkTM that provides very low instrumentation costs.…”

mentioning

confidence: 99%

Low-overhead software transactional memory with progress guarantees and strong semantics

et al. 2015

View full text Add to dashboard Cite

Software transactional memory offers an appealing alternative to locks by improving programmability, reliability, and scalability. However, existing STMs are impractical because they add high instrumentation costs and often provide weak progress guarantees and/or semantics.This paper introduces a novel STM called LarkTM that provides three significant features. (1) Its instrumentation adds low overhead except when accesses actually conflict, enabling low single-thread overhead and scaling well on low-contention workloads. (2) It uses eager concurrency control mechanisms, yet naturally supports flexible conflict resolution, enabling strong progress guarantees. (3) It naturally provides strong atomicity semantics at low cost.LarkTM's design works well for low-contention workloads, but adds significant overhead under higher contention, so we design an adaptive version of LarkTM that uses alternative concurrency control for high-contention objects.An implementation and evaluation in a Java virtual machine show that the basic and adaptive versions of LarkTM not only provide low single-thread overhead, but their multithreaded performance compares favorably with existing high-performance STMs.

show abstract

A speculation‐friendly binary search tree

Crain

Gramoli

Raynal

2018

Concurrency and Computation

View full text Add to dashboard Cite

Abstract:We introduce the first binary search tree algorithm designed for speculative executions. Prior to this work, tree structures were mainly designed for their pessimistic (non-speculative) accesses to have a bounded complexity. Researchers tried to evaluate transactional memory using such tree structures whose prominent example is the red-black tree library developed by Oracle Labs that is part of multiple benchmark distributions. Although well-engineered, such structures remain badly suited for speculative accesses, whose step complexity might raise dramatically with contention.We show that our speculation-friendly tree outperforms the existing transaction-based version of the AVL and the red-black trees. Its key novelty stems from the decoupling of update operations: they are split into one transaction that modifies the abstraction state and multiple ones that restructure its tree implementation in the background. In particular, the speculation-friendly tree is shown correct, reusable and it speeds up a transaction-based travel reservation application by up to 3.5×. Key-words: Transactional Memory, concurrent data structures, balanced binary treesUn arbre binaire de recherche dédié aux accès transactionnels Résumé : Les transactions, qui utilisent une technique de synchronisation optimiste, simplifient la programmation des architectures multi-coeurs. En effet, un programmeur a seulement besoin d'insérer des opérations dans des transactions afin d'obtenir un programme concurrent correct. Les programmeurs ont donc tout naturellement utilisé cette encapsulation sur plusieurs structures de données originellement dédiéesà la programmation pessimiste (non optimistes) pourévaluer les transactions. L'exemple le plus probantétant l'arbre transactionnel rouge-noir développé par Oracle Labs et présent dans plusieurs distributions.Malheureusement, ces structures de données ne sont pas adaptéesà des exécutions optimistes car elles reposent sur des invariants contraignants, comme la profondeur logarithmique d'un arbre, pour borner le coût des accès pessimistes. Une telle complexité ne s'applique pas aux accés optimistes et garantir de tels invariants n'est pas nécessaire et induit de la contention en augmentant la probabilité pour une transaction d'avorter et de recommencer.Dans ce papier, nous présentons un arbre binaire de recherche qui viole de façon transitoire ces invariants pour gagner en efficacité. Nous montrons que cet arbre est plus efficace que les arbres AVL et rouge-noir. Sa nouveauté majeure réside dans la séparation de ses opérations de modifications : elles sont coupées en une transaction qui modifie l'abstraction et plusieurs autres qui restructurent son implémentation. La bibliothèque qui en résulte limite la quantité d'avortements en augmentant légèrement le nombre d'accès, en particulier, elle améliore une application de réservation de voyage basée sur les transactions par un facteur multiplicatif de 3,5.

show abstract

Kicking the tires of software transactional memory

Cited by 80 publications

References 22 publications

Why STM can be more than a research toy

Why STM can be more than a research toy

Low-overhead software transactional memory with progress guarantees and strong semantics

A speculation‐friendly binary search tree

Contact Info

Product

Resources

About