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
•
03 Jul 2007TL;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
••
10 Apr 2012TL;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
•
30 Nov 2009TL;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
••
23 May 2009TL;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
••
13 Sep 2010TL;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