Transactional memory

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

Implementation of Intel Restricted Transactional Memory ISA Extension in Simics

Abstract: Hardware transactional memory is finally becoming available in products from major vendors. Recently Intel announced that a set of transactional synchronization extensions (TSX) will be available in its next processor microarchitecture, codenamed Haswell. The benefits of software simulation of this technology will remain significant even after processors that support new instructions are available on the market. The reason for this is that a simulation often provides more flexibility during debugging and architecture exploration. In this paper we describe an implementation of Intel® restricted transactional memory (RTM) instructions, which are a part of the Intel® TSX, in the full system functional simulator Wind River® Simics. Our goal was to enable correct execution of these new instructions during all stages of operating system boot and user-level application execution and at the same time to keep the high simulation speed that Simics is able to demonstrate. This model is used to enable pre-silicon software development.

Towards scalable and transparent parallelization of multiplayer games using transactional memory support

Abstract: This work addresses the problem of parallelizing multiplayer games using software Transactional Memory (STM) support. Using a realistic high impact application, we show that STM provides not only e...

Adaptive concurrency control using hardware transactional memory and locking mechanism

Abstract: A method includes the following steps. Runtime statistics related to data transaction processing in a concurrent system are collected. A given request to access shared data in the concurrent system is receive. Based on the collected runtime statistics, the number of reattempts the given request can make to access the shared data prior to access control being switched from a hardware transactional memory to a locking mechanism is adaptively determined.

A theory of nested speculative execution

Abstract: Implementing distributed applications is a challenging task. Developers are confronted with issues like fault-tolerance, efficient synchronization mechanisms, and the correctness of the distributed code. Transactions are a simple and powerful mechanism for establishing fault-tolerance. To allow multiple processes to cooperate in a transaction we relax the isolation property. We call the new abstraction a speculation. This paper introduces a new programming model based on speculative execution. Speculations provide distributed coordinated rollback and enable optimistic execution of synchronization points. We present an operational semantics for nested speculative execution that specifies distributed speculations precisely. We also discuss two approaches to implementing support for speculations.

Safety of Deferred Update in Transactional Memory

Abstract: Transactional memory allows the user to declare sequences of instructions as speculative \emph{transactions} that can either \emph{commit} or \emph{abort}. If a transaction commits, it appears to be executed sequentially, so that the committed transactions constitute a correct sequential execution. If a transaction aborts, none of its instructions can affect other transactions. The popular criterion of \emph{opacity} requires that the views of aborted transactions must also be consistent with the global sequential order constituted by committed ones. This is believed to be important, since inconsistencies observed by an aborted transaction may cause a fatal irrecoverable error or waste of the system in an infinite loop. Intuitively, an opaque implementation must ensure that no intermediate view a transaction obtains before it commits or aborts can be affected by a transaction that has not started committing yet, so called \emph{deferred-update} semantics. In this paper, we intend to grasp this intuition formally. We propose a variant of opacity that explicitly requires the sequential order to respect the deferred-update semantics. We show that our criterion is a safety property, i.e., it is prefix- and limit-closed. Unlike opacity, our property also ensures that a serialization of a history implies serializations of its prefixes. Finally, we show that our property is equivalent to opacity if we assume that no two transactions commit identical values on the same variable, and present a counter-example for scenarios when the "unique-write" assumption does not hold.