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
Proceedings ArticleDOI
08 Dec 2010
TL;DR: This paper describes how to build Simulation System of Earthquake Precursory Observatory Equipment (SSEPOE) using Dynamic Software Transactional Memory (DSTM) and compares the scalability of it to that of lock-based one and shows that the performance of SSE POE based on STM have no advantages than lock- based one.
Abstract: Transactional Memory(TM) is being studied widely by researchers, which is viewed as a new parallel programming model for synchronizing concurrent accesses to shared data object in multi-core or many-core systems. Research result shows that TM has a good performance over Lock using micro-benchmarks. The performance of real applications based on TM is still not clear. In this paper, we describe how to build Simulation System of Earthquake Precursory Observatory Equipment (SSEPOE) using Dynamic Software Transactional Memory (DSTM) and compare the scalability of it to that of lock-based one. Experimental result shows that the performance of SSEPOE based on STM have no advantages than lock-based one and it has a little convenience than lock in programming SSEPOE, this is because SSEPOE is rather simple and the experimentation computer only has two cores. If the computer has more cores and the real application is more complex, the version based on STM will outperform the lock-based one. Another hand, because DSTM2 did not support long transactions, SSEPOE Server did not realize all synchronization of threads using transactions. We only used transactions in the execution process of command instead of locks. We also gave insights into development techniques to encounter in developing SSEPOE Server and discussed the shortcomings of DSTM APIs.
01 Jan 2011
TL;DR: A transactional concurrent programming approach, based on Petri nets, is presented, which can easily specify concurrency among transactions and do not aggravate programmers remarkably in writing correct transactionalurrency programs.
Abstract: As newly developed transactional memory technology has received significant attention as a way to dramatically simplify sharedmemory concurrent programming, user-level transactional concurrent programming models have become a very interesting topic in the programming community. However, the fact is that, in existing transactional concurrent programming models, user-level mechanisms have not been well developed. The dilemma is how to make a balance between the performance and correctness of a program. Explicit concurrency among cooperative transactions can undoubtedly decrease the rate of conflicts and improve the performance, but it is harmful to the correctness. In this paper, a transactional concurrent programming approach, based on Petri nets, is presented, which can easily specify concurrency among transactions and do not aggravate programmers remarkably in writing correct transactional concurrent programs. In this approach, a special Petri net system with transition markings is developed. Although such a Petri net system is not defined conventionally, it is shown that its behavior can be simulated through a conventional net, so existing analysis and verification approaches for usual Petri nets can be applied indirectly.
01 Jan 2008
TL;DR: This work proposes a hybrid transactional memory system, the UFO Hybrid, in which high-performance hardware transactions can run concurrently with large, long, nested, or side-effecting software transactions, and offers a strongly atomic programming model for both its hardware and its software transactions.
Abstract: Transactional memory is a promising technique for multithreaded synchronization and concurrency which has attracted much interest in recent years. Compared to locks, transactions can offer increased concurrency, composability, and deadlock freedom; yet their speculative nature introduces problems not seen in lock-based code, and these have limited the adoption of transactions as a serious alternative to locks. Specifically, it is not clear how transactions can contain side-effecting actions like I/O, nor how they can scale to arbitrary footprints and durations while retaining acceptable performance and a consistent and desirable programming semantic. I believe that addressing problems like these is of first importance to programmers considering using transactions. In this work, I seek to extend the programmability of transactions by exploring and addressing these problems. I begin by exploring the domain of hardware support for software transactional memory. I first show how a general-purpose user-mode memory protection system can be used to provide strong isolation to software transactional memory systems with little hardware and minimal performance overhead. Then I show how to augment this strongly atomic software transactional memory system with a 'best-effort' hardware transactional memory system to yield a hybrid transactional memory system, the UFO Hybrid, in which high-performance hardware transactions can run concurrently with large, long, nested, or side-effecting software transactions. Compared to previous hybrid transactional memory proposals, my system offers a strongly atomic programming model for both its hardware and its software transactions, low-overhead conflict detection between its hardware and software transactions, and high HTM performance even in the presence of potentially-conflicting software transactions. I show through experimental analysis that the UFO Hybrid performs at least as well as competing hybrid transactional memory systems, and significantly outperforms them when some transactions are forced to fail over to software. I also provide an analysis of I/O in lock-based critical sections in large multithreaded workloads, with observations on how this I/O could be performed in transactional code. In this analysis, I find that no one of the previously proposed techniques is by itself sufficient for handling side-effects without sacrificing performance. However, I conclude that the majority of transactional I/O is likely to be compensatable, and that causing transactions performing I/O to 'go nonspeculative' can be a reasonable choice for uncompensated I/O, provided that it does not delay non-side effecting transactions.
Proceedings ArticleDOI
05 May 2014
TL;DR: The focus of this paper is on tolerating byzantine faults on optimistic processing of interactive and declared transactions using STM and the result is an algorithm named Mesobi.
Abstract: Recently, researchers have shown an increased interest in concurrency control using distributed Software Transactional Memory (STM). However, there has been little discussion about certain types of fault tolerance, such as Byzantine Fault Tolerance (BFT), for kind of systems. The focus of this paper is on tolerating byzantine faults on optimistic processing of interactive and declared transactions using STM. The result is an algorithm named Mesobi. The processing of a transaction runs with an optimistic approach, benefiting from the high probability of messages being delivered in order when using Reliable Multicast on a local network (LAN). The protocol performs better when messages are delivered ordered. In case of a malicious replica or out-of-order messages, the Byzantine protocol is initiated.
Journal ArticleDOI
TL;DR: The lock-free implementation of Treap is described in this study, and the results of the experiment carried out on lock-based and TSX-based Treap reveal the feasibility of this approach for building a lock- free data structure.

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