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 published on a yearly basis
Papers
More filters
••
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.
••
01 Jan 2022
••
09 Jun 2020TL;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
••
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.