Exploiting distributed version concurrency in a transactional memory cluster

Abstract

We investigate a transactional memory runtime system providing scaling and strong consistency for generic C++ and SQL applications on commodity clusters. We introduce a novel page-level distributed concurrency control algorithm, called Distributed Multiversioning (DMV). DMV automatically detects and resolves conflicts caused by data races for distributed transactions accessing shared in-memory data structures. DMV's key novelty is in exploiting the distributed data versions that naturally occur in a replicated cluster in order to avoid read-write conflicts. Specifically, DMV runs conflicting transactions in parallel on different replicas, instead of using different physical data copies within a single node as in classic multiversioning.In its most general update-anywhere configuration, DMV can be used to implement a software transactional memory abstraction for classic distributed shared memory applications. DMV supports scaling for highly multithreaded database applications as well by centralizing updates on a master replica and creating the required page versions for read-only transactions on a set of slaves. In this DMV configuration, a version-aware scheduling technique distributes the read-only transactions across the slaves in such a way to minimize version conflicts.In our evaluation, we use DMV as a lightweight approach to scaling a hash table microbenchmark workload and the industrystandard e-commerce workload of the TPC-W benchmark on a commodity cluster. Our measurements show scaling for both benchmarks. In particular, we show near-linear scaling up to 8 transactional nodes for the most common e-commerce workload, the TPC-W shopping mix. We further show that our scaling for the TPC-W e-commerce benchmark compares favorably with that of an existing coarse-grained asynchronous replication technique.

Automatic speculative DOALL for clusters

“…The runtime system tracks every speculative memory operation within a transaction or task (i.e., region of code executed speculatively) to determine if any atomicity violation (in TM) or dependence violation (in TLS) occurs at commit time. Proposals for TM or TLS memory systems can be divided into two classes: hardware-based approaches [21,24,23] and software-only approaches [4,6,8,9,12,13,14,17,22]. Software-only approaches can be further divided depending on whether they require cache-coherent shared memory or not.…”

AGGRO: Boosting STM Replication via Aggressively Optimistic Transaction Processing

“…Finally, our work is clearly related to the recent literature on distributed STMs [4,6,15,16]. However, except [6], none of these solutions leverages on replication in order to enhance system dependability.…”

TM 2 C

“…They were dedicated to shared memory systems, all relying on an underlying hardware cachecoherence [35,36]. More recently, much effort was spent in implementing the TM abstraction on top of clusters of distributed machines, resulting in various distributed transactional memories (DTMs) [5,25,27,33].This distribution unveiled new research challenges, whose prominent one is possibly to guarantee transaction termination despite messagebased synchronization. Our solution is the first to exploit many-cores to provide efficient transactions that are guaranteed to terminate.…”

“…Distributed Multi-Versioning (DMV) [27] is a replicated DTM that exploits multi-version concurrency control to minimize the number of aborts. DMV operates in two different modes.…”