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
John Joseph Duffy1, Michael M. Magruder1, Goetz Graefe1, David Detlefs1, Vinod Grover1 
03 Jul 2007
TL;DR: In this paper, a transactional memory word is provided for each piece of data, which includes a version number, a reader indicator, and an exclusive writer indicator for concurrency control.
Abstract: Various technologies and techniques are disclosed that improve implementation of concurrency control modes in a transactional memory system. A transactional memory word is provided for each piece of data. The transactional memory word includes a version number, a reader indicator, and an exclusive writer indicator. The transactional memory word is analyzed to determine if the particular concurrency control mode is proper. Using the transactional memory word to help with concurrency control allows multiple combinations of operations to be performed against the same memory location simultaneously and/or from different transactions. For example, a pessimistic read operation and an optimistic read operation can be performed against the same memory location.

30 citations

Proceedings ArticleDOI
10 Apr 2012
TL;DR: A specialized STM system that allows the program to express additional knowledge about the particular operations being performed by transactions e.g., using a separate API to write transactions that access small, fixed, numbers of memory locations is presented.
Abstract: Data structures implemented using software transactional memory (STM) have a reputation for being much slower than data structures implemented directly from low-level primitives such as atomic compare-and-swap (CAS). In this paper we present a specialized STM system (SpecTM) that allows the program to express additional knowledge about the particular operations being performed by transactions e.g., using a separate API to write transactions that access small, fixed, numbers of memory locations. We show that data structures implemented using SpecTM offer essentially the same performance and scalability as implementations built directly from CAS. We present results using hash tables and skip lists on machines with up to 8 sockets and up to 128 hardware threads. Specialized transactions can be mixed with normal transactions, allowing fast-path operations to be specialized for greater performance, while allowing less common cases to be expressed using normal transactions for simplicity. We believe that SpecTM provides a "sweet spot" for expert programmers developing scalable data structures.

29 citations

Patent
30 Nov 2009
TL;DR: In this paper, the authors propose an apparatus, method, and system for implementing a hardware transactional memory (HTM) system with multiple levels of transactional buffers, which includes a data cache configured to buffer data in a shared memory accessed by speculative memory access operations and to retain the data during at least a portion of an attempt to execute the atomic memory transaction.
Abstract: An apparatus, method, and system for implementing a hardware transactional memory (HTM) system with multiple levels of transactional buffers. The apparatus comprises a data cache configured to buffer data in a shared (by a plurality of processing cores) memory accessed by speculative memory access operations and to retain the data during at least a portion of an attempt to execute the atomic memory transaction. The apparatus also comprises an overflow detection circuit configured to detect an overflow condition upon determining that the data cache has insufficient capacity to buffer a portion of data accessed as part of the atomic memory transaction, as well as a buffering circuit configured to respond to the detection of the overflow condition by preventing the portion of data from being buffered in the data cache and buffering the portion of data in a secondary buffer separate from the data cache.

29 citations

Proceedings ArticleDOI
23 May 2009
TL;DR: This work proposes the concept of lightweight debug transactions that exploit the conflict detection mechanisms of transactional memory systems to perform data race detection, and presents a proof-of-concept simulation prototype and experiments show that this technique is effective at discovering data races and has low performance overhead.
Abstract: Widespread emergence of multicore processors will spur development of parallel applications, exposing programmers to degrees of hardware concurrency hitherto unavailable. Dependable multithreaded software will have to rely on the ability to dynamically detect non-deterministic and notoriously hard to reproduce synchronization bugs manifested through data races. Previous solutions to dynamic data race detection have required specialized hardware, at additional power, design and area costs. We propose RaceTM, a novel approach to data race detection that exploits hardware that will likely be present in future multiprocessors, albeit for a different purpose. In particular, we show how emerging hardware support for transactional memory can be leveraged to aid data race detection. We propose the concept of lightweight debug transactions that exploit the conflict detection mechanisms of transactional memory systems to perform data race detection. We present a proof-of-concept simulation prototype, and evaluate it on data races injected into applications from the SPLASH-2 suite. Our experiments show that this technique is effective at discovering data races and has low performance overhead.

29 citations

Book ChapterDOI
13 Sep 2010
TL;DR: This work argues that traditional synchronization objects, such as locks, conditions, and atomic/volatile variables, should be defined in terms of transactions, rather than the other way around, and shows that selective relaxation of the relationship between program order and transaction order can allow the implementation of transaction-based locks to be as efficient as conventional locks.
Abstract: We argue that traditional synchronization objects, such as locks, conditions, and atomic/volatile variables, should be defined in terms of transactions, rather than the other way around. A traditional critical section, in particular, is a region of code, bracketed by transactions, in which certain data have been privatized. We base our memory model on the notion of strict serializability (SS), and show that selective relaxation of the relationship between program order and transaction order can allow the implementation of transaction-based locks to be as efficient as conventional locks. We also show that condition synchronization can be accommodated without explicit mention of speculation, opacity, or aborted transactions. Finally, we compare SS to the notion of strong isolation (SI), arguing that SI is neither sufficient for transactional sequential consistency (TSC) nor necessary in programs that are transactional data-race free (TDRF).

29 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