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
Patent
22 Sep 2005
TL;DR: In this paper, a technique for improving the performance of a system that supports simultaneous multi-threading (SMT) is proposed, where a first thread encounters a halt sequence, and a second thread stores to the mailbox address, which causes a transactional-memory mechanism within the processor to detect an interference with the previous load from a mailbox address by the first thread and to exit from the halt sequence.
Abstract: A technique for improving the performance of a system that supports simultaneous multi-threading (SMT). When a first thread encounters a halt sequence, the system starts a transactional memory operation by generating a checkpoint and entering a transactional-execution mode. Next, the system loads from a mailbox address associated with the halt sequence. The system then stalls execution of the first thread, so that the first thread does not execute instructions within the halt sequence, thereby freeing up processor resources for other threads. To terminate the halt sequence, a second thread stores to the mailbox address, which causes a transactional-memory mechanism within the processor to detect an interference with the previous load from the mailbox address by the first thread and which causes the first thread to exit from the halt sequence. The system then continues executing instructions following the halt sequence.

10 citations

Proceedings ArticleDOI
16 Apr 2010
TL;DR: An adaptive signature AdapSig is presented to adapt the number and length of bit vectors to the size of read/write sets keeping an acceptable false positive rate and implemented in STM which is different from hardware implementation.
Abstract: Transactional Memory(TM) is a promising way to coordinate concurrent threads in multi-core processors. Software transactional memory (STM) can run on conventional processors without additional hardware support. It is an option before TMs are available in commercial multi-core processors. Several TM systems use signatures to track items read and written during a transaction and to detect conflicts between transactions. Signatures summarize unbounded read/write sets in bounded bit vectors at a cost of false positives (conflicts detected when none exists). Most signatures are implemented in hardware. The size of read/write sets in different applications fluctuates in a wide range which makes it difficult to decide the size signatures. It will waste resources with long signature and cause higher false positive rate with short one. In this paper we present an adaptive signature AdapSig to detect conflicts in STM. The idea is to adapt the number and length of bit vectors to the size of read/write sets keeping an acceptable false positive rate. We implement it in STM which is different from hardware implementation. We evaluate AdapSig with a transactional benchmark suit named STAMP and improve execution time by up to 10% comparing the original one in RSTM.

10 citations

Proceedings ArticleDOI
25 Oct 2010
TL;DR: It is proposed that Transactional memory (TM) is a good match to software packet processing: it both can allow the system to optimistically exploit parallelism between the processing of packets whenever it is safe to do so, and is easy-to-use for a programmer.
Abstract: Software packet processing is becoming more important to enable differentiated and rapidly-evolving network services With increasing numbers of programmable processor and accelerator cores per network node, it is a challenge to support sharing and synchronization across them in a way that is scalable and easy-to-program In this paper, we focus on parallel/threaded applications that have irregular control-flow and frequently-updated shared state that must be synchronized across threads However, conventional lock-based synchronization is both difficult to use and also often results in frequent conservative serialization of critical sections Alternatively, we propose that Transactional memory (TM) is a good match to software packet processing: it both (i) can allow the system to optimistically exploit parallelism between the processing of packets whenever it is safe to do so, and (ii) is easy-to-use for a programmer With the NetFPGA [1] platform and four network packet processing applications that are threaded and share memory, we evaluate hardware support for TM (HTM) using the reconfigurable FPGA fabric Relative to NetThreads [2], our two-processor four-way-multithreaded system with conventional lock-based synchronization, we find that adding HTM achieves 6%, 54% and 57% increases in packet throughput for three of four packet processing applications studied, due to reduced conservative serialization

10 citations

Book ChapterDOI
01 Jan 2011
TL;DR: An analysis of the four controller models' response characteristics to changes in dynamic available parallelism, and identifies weaknesses that reduce their general applicability lead to the design of a fifth controller model, called P-only transactional concurrency tuning (PoCC).
Abstract: Applications using transactional memory may exhibit fluctuating (dynamic) available parallelism, i.e. the maximum number of transactions that can be committed concurrently may change over time. Executing large numbers of transactions concurrently in phases with low available parallelism will waste processor resources in aborted transactions, while executing few transactions concurrently in phases with high available parallelism will degrade execution time by not fully exploiting the available parallelism. Three questions come to mind: (1) Are there such transactional applications? (2) How can such behaviour be exploited? and (3) How can available parallelism be measured or calculated efficiently? The contributions of this paper constitute the answers to these questions. This paper presents a system, called transactional concurrency tuning, that adapts the number of transactions executing concurrently in response to dynamic available parallelism, in order to improve processor resource usage and execution time performance. Four algorithms, called controller models, that vary in response strength were presented in previous work and shown to maintain execution time similar to the best case non-tuned execution time, but improve resource usage significantly in benchmarks that exhibit dynamic available parallelism. This paper presents an analysis of the four controller models' response characteristics to changes in dynamic available parallelism, and identifies weaknesses that reduce their general applicability. These limitations lead to the design of a fifth controller model, called P-only transactional concurrency tuning (PoCC). Evaluation of PoCC shows it improves upon performance and response characteristics of the first four controller models, making it a robust controller model suitable for general use.

10 citations

Proceedings ArticleDOI
15 Oct 2016
TL;DR: This work presents COMMTM, an HTM that exploits semantic commutativity and extends the coherence protocol and conflict detection scheme to support user-defined commutative operations, and preserves transactional guarantees and can be applied to arbitrary HTMs.
Abstract: Hardware speculative execution schemes such as hardware transactional memory (HTM) enjoy low run-time overheads but suffer from limited concurrency because they rely on reads and writes to detect conflicts. By contrast, software speculation schemes can exploit semantic knowledge of concurrent operations to reduce conflicts. In particular, they often exploit that many operations on shared data, like insertions into sets, are semantically commutative: they produce semantically equivalent results when reordered. However, software techniques often incur unacceptable run-time overheads. To solve this dichotomy, we present COMMTM, an HTM that exploits semantic commutativity. CommTM extends the coherence protocol and conflict detection scheme to support user-defined commutative operations. Multiple cores can perform commutative operations to the same data concurrently and without conflicts. CommTM preserves transactional guarantees and can be applied to arbitrary HTMs. CommTM scales on many operations that serialize in conventional HTMs, like set insertions, reference counting, and top-K insertions, and retains the low overhead of HTMs. As a result, at 128 cores, CommTM outperforms a conventional eager-lazy HTM by up to 3.4 χ and reduces or eliminates aborts.

10 citations


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