scispace - formally typeset
Search or ask a question
Topic

Transactional memory

About: Transactional memory is a research topic. Over the lifetime, 2365 publications have been published within this topic receiving 60818 citations.


Papers
More filters
Journal ArticleDOI
TL;DR: The use of a rollback buffer (RB) for hiding the rollback latency in log-based eager hardware transactional memory is proposed, and when running the Stanford transactional applications for multi-processing benchmark on a 16-core processor that implements the LogTM-SE, the speedup is almost disappears.
Abstract: The use of a rollback buffer (RB) for hiding the rollback latency in log-based eager hardware transactional memory is proposed. The RB allows a transaction to abort without performing rollback, but still makes the transaction's old values immediately available. In effect, the rollback latency almost disappears. When running the Stanford transactional applications for multi-processing benchmark on a 16-core processor that implements the LogTM-SE, the speedup (decrease in execution time) achieved with a 2 KB RB is 15.8% on average.
Proceedings ArticleDOI
09 Jun 2020
TL;DR: New realistic assumptions relative to real-time systems are introduced, which allow to ensure wait-freedom guarantees progress when Polka contention manager is considered and prove upper bounds both on the number of abortions and on the execution time of transactions.
Abstract: Transactional memory (TM) draws the attention of both academic and development groups; indeed this concept offers an alternative to lock-based approaches, easing programmers' work. Despite the large amount of investigations around this topic, the question of the correctness of most TM implementations remains open. More specifically, the lack of upper bounds on the execution time of transactions prevents the use of TM in real-time systems. To address this issue, we introduce new realistic assumptions relative to real-time systems, which allow to ensure wait-freedom guarantees progress (i.e. all transactions progress) when Polka contention manager is considered. In that context, through a thorough formalization of the system, we prove upper bounds both on the number of abortions and on the execution time of transactions.
01 Jan 2013
TL;DR: The definition of a model of a TM with irrevocable operations and the impact of side-effects on correctness were described, as well as the costs and benefits of using this model, were described.
Abstract: 2 Description of the work carried out during the STSM 2 2.1 Defining model of a TM with irrevocable operations . . . . . . . . . . . . . . . . 2 2.2 Reasoning about the correctness of a TM with irrevocable support . . . . . . . . 3 2.3 Impact of side-effects on correctness . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.4 The number of irrevocable transactions at a time . . . . . . . . . . . . . . . . . . 4 2.5 Liveness of a TM with irrevocable support . . . . . . . . . . . . . . . . . . . . . . 5 2.5.1 Transiting to the irrevocable state . . . . . . . . . . . . . . . . . . . . . . 6 2.5.2 Liveness of revocable transactions while an irrevocable is live . . . . . . . 6 2.6 Re-using existing properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.7 Cost of adding irrevocability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.8 Obstruction-freedom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.9 Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Journal ArticleDOI
TL;DR: This paper applies a runtime environment to recognize application's dynamic behaviors and resolve transactional conflicts to make up the gap between the upper layer application's diversity and the underline hardware's capability and finds that this proposal can obtain a significant performance improvement across the applications selected from the STAMP benchmark suite on DynTM.
Abstract: As one of the most potential solution to improve thread level parallelism and reduce most ordinary programmers' burden on parallel programming, transactional memory (TM) systems have attracted a great deal of attention from both industry and academic since the notion was proposed in 1993. Since then, various designs and implementations are proposed to improve the performance while reducing the overheads. However, recent investigations of the high-contention and coarse-grained workloads reveal various pathologies that will offset the performance benefits. In this paper, we analysis the advantages and disadvantages of existing conflict management and version management schemes, make a case study in the interplay of them to learn its impact on performance. In particular, we apply a runtime environment to recognize application's dynamic behaviors and resolve transactional conflicts to make up the gap between the upper layer application's diversity and the underline hardware's capability. Throughout the comprehensive evaluation, we find that our proposal can obtain a significant performance improvement across the applications selected from the STAMP benchmark suite on DynTM, which is regarded as one of the latest progress in HTM systems.

Network Information
Related Topics (5)
Compiler
26.3K papers, 578.5K citations
87% related
Cache
59.1K papers, 976.6K citations
86% related
Parallel algorithm
23.6K papers, 452.6K citations
84% related
Model checking
16.9K papers, 451.6K citations
84% related
Programming paradigm
18.7K papers, 467.9K citations
83% related
Performance
Metrics
No. of papers in the topic in previous years
YearPapers
202316
202240
202129
202063
201970
201888