Transactional memory

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

Coalescing memory transactions

Abstract: A transactional memory system coalesces two outermost transactions in a transactional memory environment. A processor of the transactional memory system executes a first transaction begin instruction of a first outermost transaction and processes the first transaction. Based on encountering a first transaction end instruction of the first outermost transaction, the processor determines whether the first transaction is to-be coalesced with a second outermost transaction.

Versioned transactional shared memory for the FénixEDU web application

Abstract: The FenixEDU system uses a novel infrastructure for web applications based on the Versioned Software Transactional Memory (VSTM) abstraction. The FenixEDU system has been deployed and is currently in operation in different facilities, including the Instituto Superior Tecnico where it serves the entire academic community, processing between 1,000,000 and 4,500,000 transactions per day.This paper describes the ongoing work on the infrastructure support, in order to increase its scalability and fault-tolerance. For that purpose we are developing a distributed version of the VSTM, such that multiple application servers can concurrently serve different request and still coordinate in an efficient manner to provide strong consistency guarantees to the applications.

Fractal: An Execution Model for Fine-Grain Nested Speculative Parallelism

Abstract: Most systems that support speculative parallelization, like hardware transactional memory (HTM), do not support nested parallelism. This sacrifices substantial parallelism and precludes composing parallel algorithms. And the few HTMs that do support nested parallelism focus on parallelizing at the coarsest (shallowest) levels, incurring large overheads that squander most of their potential.We present FRACTAL, a new execution model that supports unordered and timestamp-ordered nested parallelism. FRACTAL lets programmers seamlessly compose speculative parallel algorithms, and lets the architecture exploit parallelism at all levels. FRACTAL can parallelize a broader range of applications than prior speculative execution models. We design a FRACTAL implementation that extends the Swarm architecture and focuses on parallelizing at the finest (deepest) levels. Our approach sidesteps the issues of nested parallel HTMs and uncovers abundant fine-grain parallelism. As a result, FRACTAL outperforms prior speculative architectures by up to 88x at 256 cores.

Generic Multiversion STM

Abstract: Multiversion software transactional memory STM allows a transaction to read old values of a recently updated object, after which the transaction may serialize before transactions that committed earlier in physical time. This ability to "commit in the past" is particularly appealing for long-running read-only transactions, which may otherwise starve in many STM systems, because short-running peers modify data out from under them before they have a chance to finish. Most previous approaches to multiversioning have been designed as an integral part of some larger STM system, and have assumed an object-oriented, garbage-collected language. We describe, instead, how multiversioning may be implemented on top of an almost arbitrary "word-based" STM system. To the best of our knowledge, ours is the first work for any kind of STM to combine bounded space consumption with guaranteed wait freedom for read-only transactions in the form presented here, it may require writers to be blocking. We make no assumptions about data or metadata layout, though we do require that the base system provide a hash function with certain ordering properties. We neither require nor interfere with automatic garbage collection. Privatization safety can be ensured--without compromising wait freedom for readers--either by forcing privatizing writers to wait for all extant readers or by requiring that programmers explicitly identify the data being privatized.

Hardware Transactional Memory Meets Memory Persistency

Abstract: Persistent Memory (PM) and Hardware Transactional Memory (HTM) are two recent architectural developments whose joint usage promises to drastically accelerate the performance of concurrent, data-intensive applications. Unfortunately, combining these two mechanisms using existing architectural supports is far from being trivial. This paper presents NV-HTM, a system that allows the execution of transactions over PM using unmodified commodity HTM implementations. NV-HTM relies on a hardware-software co-design technique, which is based on three key ideas: i) relying on software to persist transactional modifications after they have been committed via HTM; ii) postponing the externalization of commit events to applications until it is ensured, via software, that any data version produced and observed by committed transactions is first logged in PM; ii) pruning the commit logs via checkpointing schemes that not only bound the log space and recovery time, but also implement wear levelling techniques to enhance PM's endurance. By means of an extensive experimental evaluation, we show that NV-HTM can achieve up to 10× speed-ups and up to 11.6× reduced flush operations with respect to state of the art solutions, which, unlike NV-HTM, require custom modifications to existing HTM systems.