Crafty: efficient, HTM-compatible persistent transactions

Genç, Kaan; Bond, Michael D.; Xu, Guoqing

doi:10.1145/3385412.3385991

Cited by 19 publications

(5 citation statements)

References 25 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…There is a great deal of work on building programming systems that allow developers to use PM in a reliable way without knowing the details of PM. For example, a line of work [3,8,15,16,34,57] proposes to use (software or hardware) transactions to provide (failure and thread) atomicity. Another line of work [1,4,20,25,35] advocates use of locks or synchronization-free regions [17].…”

Section: Related Workmentioning

confidence: 99%

Yashme: detecting persistency races

Gorjiara

Demsky

2022

Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems

Self Cite

View full text Add to dashboard Cite

Persistent memory (PM) or Non-Volatile Random-Access Memory (NVRAM) hardware such as Intel's Optane memory product promises to transform how programs store and manipulate information. Ensuring that persistent memory programs are crash consistent is a major challenge. We present a novel class of crash consistency bugs for persistent memory programs, which we call persistency races. Persistency races can cause non-atomic stores to be made partially persistent. Persistency races arise due to the interaction of standard compiler optimizations with persistent memory semantics.We present Yashme, the first detector for persistency races. A major challenge is that in order to detect persistency races, the execution must crash in a very narrow window between a store with a persistency race and its corresponding cache flush operation, making it challenging for naïve techniques to be effective. Yashme overcomes this challenge with a novel technique for detecting races in executions that are prefixes of the pre-crash execution. This technique enables Yashme to effectively find persistency races even if the injected crashes do not fall into that window. We have evaluated Yashme on a range of persistent memory benchmarks and have found 24 real persistency races that have never been reported before. CCS CONCEPTS• Hardware → Memory and dense storage; • Software and its engineering → Software verification and validation; Compilers.

show abstract

Section: Related Workmentioning

confidence: 99%

Yashme: detecting persistency races

Gorjiara

Demsky

2022

Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems

Self Cite

View full text Add to dashboard Cite

show abstract

“…Notice that this approach is different from ours and needs a shared shadow memory, besides persistent memory where that data is. Genc et al [44] proposed a low overhead HTM compatible persistent transactional system, called Crafty, using eager versioning. Joshi et al [45] proposed a persistent HTM system providing a hardware support for lazy versioning to reduce the performance overhead compared to software based implementations.…”

Section: Persistent Tm Systemsmentioning

confidence: 99%

Adaptive Versioning in Transactional Memory Systems

Poudel

Sharma

2021

Algorithms

View full text Add to dashboard Cite

Transactional memory has been receiving much attention from both academia and industry. In transactional memory, program code is split into transactions, blocks of code that appear to execute atomically. Transactions are executed speculatively and the speculative execution is supported through data versioning mechanism. Lazy versioning makes aborts fast but penalizes commits, whereas eager versioning makes commits fast but penalizes aborts. However, whether to use eager or lazy versioning to execute those transactions is still a hotly debated topic. Lazy versioning seems appropriate for write-dominated workloads and transactions in high contention scenarios whereas eager versioning seems appropriate for read-dominated workloads and transactions in low contention scenarios. This necessitates a priori knowledge on the workload and contention scenario to select an appropriate versioning method to achieve better performance. In this article, we present an adaptive versioning approach, called Adaptive, that dynamically switches between eager and lazy versioning at runtime, without the need of a priori knowledge on the workload and contention scenario but based on appropriate system parameters, so that the performance of a transactional memory system is always better than that is obtained using either eager or lazy versioning individually. We provide Adaptive for both persistent and non-persistent transactional memory systems using performance parameters appropriate for those systems. We implemented our adaptive versioning approach in the latest software transactional memory distribution TinySTM and extensively evaluated it through 5 micro-benchmarks and 8 complex benchmarks from STAMP and STAMPEDE suites. The results show significant benefits of our approach. Specifically, in persistent TM systems, our approach achieved performance improvements as much as 1.5× for execution time and as much as 240× for number of aborts, whereas our approach achieved performance improvements as much as 6.3× for execution time and as much as 170× for number of aborts in non-persistent transactional memory systems.

show abstract

“…To remove some item(s), a thread uses CAS to increase popped. For simplicity, the code exploits the fact that duplicate writes-back are semantically harmless: concurrent removing threads may iterate over overlapping ranges (lines [13][14][15][16][17][18][19][20][21].…”

Section: Bufferingmentioning

confidence: 99%

Fast Nonblocking Persistence for Concurrent Data Structures

Cai,

Wen,

Maksimovski

et al. 2021

Preprint

View full text Add to dashboard Cite

We present a fully lock-free variant of the recent Montage system for persistent data structures. Our variant, nbMontage, adds persistence to almost any nonblocking concurrent structure without introducing significant overhead or blocking of any kind. Like its predecessor, nbMontage is buffered durably linearizable: it guarantees that the state recovered in the wake of a crash will represent a consistent prefix of pre-crash execution. Unlike its predecessor, nbMontage ensures wait-free progress of the persistence frontier, thereby bounding the number of recent updates that may be lost on a crash, and allowing a thread to force an update of the frontier (i.e., to perform a sync operation) without the risk of blocking. As an extra benefit, the helping mechanism employed by our wait-free sync significantly reduces its latency.Performance results for nonblocking queues, skip lists, trees, and hash tables rival custom data structures in the literature-dramatically faster than achieved with prior general-purpose systems, and generally within 50% of equivalent non-persistent structures placed in DRAM.

show abstract

Crafty: efficient, HTM-compatible persistent transactions

Cited by 19 publications

References 25 publications

Yashme: detecting persistency races

Yashme: detecting persistency races

Adaptive Versioning in Transactional Memory Systems

Fast Nonblocking Persistence for Concurrent Data Structures

Contact Info

Product

Resources

About