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
Book ChapterDOI
06 Jun 2016
TL;DR: D-Scoop is presented, a distributed programming model that allows for interference-free and transaction-like reasoning on (potentially multiple) network objects, with synchronization handled automatically, and network failures managed by a compensation mechanism, and finds that it comes close to—or outperforms—explicit locking-based synchronization in Java RMI.
Abstract: Network objects are a simple and natural abstraction for distributed object-oriented programming. Languages that support network objects, however, often leave synchronization to the user, along with its associated pitfalls, such as data races and the possibility of failure. In this paper, we present D-Scoop, a distributed programming model that allows for interference-free and transaction-like reasoning on (potentially multiple) network objects, with synchronization handled automatically, and network failures managed by a compensation mechanism. We achieve this by leveraging the runtime semantics of a multi-threaded object-oriented concurrency model, directly generalizing it with a message-based protocol for efficiently coordinating remote objects. We present our pathway to fusing these contrasting but complementary ideas, and evaluate the performance overhead of the automatic synchronization in D-Scoop, finding that it comes close to—or outperforms—explicit locking-based synchronization in Java RMI.

5 citations

Proceedings ArticleDOI
01 Sep 2017
TL;DR: This work proposes that the hardware allow the program to specify, at the start of a transaction, that it should in all cases abort, even if it (accidentally) executes a commit instruction.
Abstract: Several research groups have noted that hardware transactional memory (HTM), even in the case of aborts, can have the side effect of warming up the branch predictor and caches, thereby accelerating subsequent execution. We propose to employ this side effect deliberately, in cases where execution must wait for action in another thread. In doing so, we allow "warm-up" transactions to observe inconsistent state. We must therefore ensure that they never accidentally commit. To that end, we propose that the hardware allow the program to specify, at the start of a transaction, that it should in all cases abort, even if it (accidentally) executes a commit instruction. We discuss several scenarios in which always-abort HTM (AAHTM) can be useful, and present lock and barrier implementations that employ it. We demonstrate the value of these implementations on several real-world applications, obtaining performance improvements of up to 2.5x with almost no programmer effort.

5 citations

01 Jan 2007
TL;DR: This paper duplicates LogTM in the M5 simulator which models operating system interactions with hardware rigorously, which disallows us to abstract the OS away from the TM system, and finds the OS needs intimate knowledge of the TM extensions to properly share the system with transactional and non-transactional threads.
Abstract: LogTM is a transactional memory (TM) implementation that is very promising. It requires moderate augmentation of existing hardware and uses software handlers to support complex operations such as rolling back the transactional memory state. LogTM has shown it oers good performance, usually outperforming lock based code while improving programmability. Currently, research in LogTM and TM in general make simplifying assumptions about how a real system will behave by abstracting away details. One such simplification is to abstract away the OS. In this paper we duplicate LogTM in the M5 simulator which models operating system interactions with hardware rigorously, which disallows us to abstract the OS away from the TM system. We find the OS needs intimate knowledge of the TM extensions to properly share the system with transactional and non-transactional threads. Because we do not abstract away the OS in M5, the OS is able to cause interference in the TM system by aborting transactions. We quantify this OS interference, and find it to be benchmark dependent. The OS causes very few aborts the majority of the time but can cause up to 42% of all aborts. In this paper we also investigate the published performance results from LogTM and find them to be correct when the transactions are assumed to be small. We extend the results using new benchmarks that do not assume small transactions, and find our new benchmarks expose pathological behavior in LogTM with up to 98% of the transactions aborting.

5 citations

Proceedings ArticleDOI
21 Jul 2015
TL;DR: This work considers scheduling problems in the data flow model of distributed transactional memory and shows that there are problem instances for which there is no scheduling algorithm that can simultaneously minimize the completion time and communication cost.
Abstract: We consider scheduling problems in the data flow model of distributed transactional memory. Objects shared by transactions move from one network node to another by following network paths. We examine how the objects' transfer in the network affects the completion time of all transactions and the total communication cost. We show that there are problem instances for which there is no scheduling algorithm that can simultaneously minimize the completion time and communication cost. These instances reveal a trade-off, minimizing execution time implies high communication cost and vice versa. On the positive side, we provide scheduling algorithms which are independently communication cost near-optimal or execution time efficient.

5 citations

Proceedings ArticleDOI
08 Jun 2009
TL;DR: This work proposes MShot, a hardware-assisted memory snapshot for concurrent programming without synchronization code, which supports atomic multi-word read operations on a large dataset and allows system services to run in parallel with user applications on spare cores in CMP systems.
Abstract: The industry-wide turn toward chip-multiprocessors (CMPs) provides an increasing amount of parallel resources for commodity systems. However, it is still difficult to harness the available parallelism in user applications and system software code.We propose MShot, a hardware-assisted memory snapshot for concurrent programming without synchronization code. It supports atomic multi-word read operations on a large dataset. Since modern processors support atomic access only to a single word, programmers should add synchronization code to process a multiword dataset concurrently in multithreading environment. With snapshot, programmers read the dataset atomically and process the snapshot image without synchronization code. We implement MShot using hardware resources for transactional memory and reduce the storage overhead from 2.98% to 0.07%. To demonstrate the usefulness of fast snapshot, we use MShot to implement concurrent versions of garbage collection and call-path profiling. Without the need for synchronization code, MShot allows such system services to run in parallel with user applications on spare cores in CMP systems. As a result, the overhead of these services

5 citations


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