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
••
04 Jan 2015TL;DR: In this article, the authors explore the costs of providing wait-freedom to only a subset of transactions and show that this kind of partial waitfreedom, combined with attractive requirements like read invisibility or disjoint-access parallelism, incurs considerable complexity costs.
Abstract: Transactional memory (TM) is a convenient synchronization tool that allows concurrent threads to declare sequences of instructions on shared data as speculative transactions with "all-or-nothing" semantics. It is known that dynamic transactional memory cannot provide wait-free progress ensuring that every transaction commits in a finite number of its own steps. In this paper, we explore the costs of providing wait-freedom to only a subset of transactions. We require that read-only transactions commit in the wait-free manner, while updating transactions are guaranteed to commit only if they run in the absence of concurrency. We show that this kind of partial wait-freedom, combined with attractive requirements like read invisibility or disjoint-access parallelism, incurs considerable complexity costs.
9 citations
•
16 Jun 2008TL;DR: In this article, various technologies and techniques are disclosed for detecting falsely doomed parent transactions of nested children in transactional memory systems, and a release count is tracked each time that a write lock is released due to rollback for a given nested transaction.
Abstract: [029] Various technologies and techniques are disclosed for detecting falsely doomed parent transactions of nested children in transactional memory systems. When rolling back nested transactions, a release count is tracked each time that a write lock is released due to rollback for a given nested transaction. For example, a write abort compensation map can be used to track the release count for each nested transaction. The number of times the nested transactions releases a write lock is recorded in their respective write abort compensation map. The release counts can be used during a validation of a parent transaction to determine if a failed optimistic read is really valid. If an aggregated release count for the nested children transactions accounts for the difference in version numbers exactly, then the optimistic read is valid.
9 citations
•
IBM1
TL;DR: Prevention of a prefetch memory operation from causing a transaction to abort as discussed by the authors : A local processor receives a request from a remote processor and determines whether the prefetch request conflicts with a transaction of the local processor.
Abstract: Prevention of a prefetch memory operation from causing a transaction to abort A local processor receives a prefetch request from a remote processor A processor determines whether the prefetch request conflicts with a transaction of the local processor A processor responds to at least one of i) a determination that the local processor has no transaction, and ii) a determination that the prefetch request does not conflict with a transaction by providing a requested prefetch data by providing a requested prefetch data A processor responds to a determination that the prefetch request conflicts with a transaction by suppressing a processing of the prefetch request
9 citations
•
IBM1
TL;DR: In this paper, a cache memory of a data processing system receives a transactional memory access request including a target address and a priority of the requesting memory transaction, and the cache memory resolves the conflict by causing cache memory to fail the requesting or existing memory transaction based at least in part on their relative priorities.
Abstract: In at least some embodiments, a cache memory of a data processing system receives a transactional memory access request including a target address and a priority of the requesting memory transaction. In response, transactional memory logic detects a conflict for the target address with a transaction footprint of an existing memory transaction and accesses a priority of the existing memory transaction. In response to detecting the conflict, the transactional memory logic resolves the conflict by causing the cache memory to fail the requesting or existing memory transaction based at least in part on their relative priorities. Resolving the conflict includes at least causing the cache memory to fail the existing memory transaction when the requesting memory transaction has a higher priority than the existing memory transaction, the transactional memory access request is a transactional load request, and the target address is within a store footprint of the existing memory transaction.
9 citations
••
01 Sep 2017TL;DR: An evaluation includes a diverse range of tree sizes and operation workloads and reveals that BSTs based on RCU-HTM outperform other alternatives by more than 18%, on average, on a multi-core server with 44 hardware threads.
Abstract: In this paper we introduce RCU-HTM, a technique that combines Read-Copy-Update (RCU) with Hardware Transactional Memory (HTM) to implement highly efficient concurrent Binary Search Trees (BSTs). Similarly to RCU-based algorithms, we perform the modifications of the tree structure in private copies of the affected parts of the tree rather than in-place. This allows threads that traverse the tree to proceed without any synchronization and without being affected by concurrent modifications. The novelty of RCU-HTM lies at leveraging HTM to permit multiple updating threads to execute concurrently. After appropriately modifying the private copy, we execute an HTM transaction, which atomically validates that all the affected parts of the tree have remained unchanged since they've been read and, only if this validation is successful, installs the copy in the tree structure.We apply RCU-HTM on AVL and Red-Black balanced BSTs and compare theirperformance to state-of-the-art lock-based, non-blocking, RCU- and HTM-basedBSTs. Our experimental evaluation reveals that BSTs implemented with RCU-HTMachieve high performance, not only for read-only operations, but also for update operations. More specifically, our evaluation includes a diverse range of tree sizes and operation workloads and reveals that BSTs based on RCU-HTM outperform other alternatives by more than 18%, on average, on a multi-core server with 44 hardware threads.
9 citations