SMV: Selective Multi-Versioning STM

Perelman, Dmitri; Byshevsky, Anton; Litmanovich, Oleg; Keidar, Idit

doi:10.1007/978-3-642-24100-0_9

Cited by 38 publications

(34 citation statements)

References 29 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…JVSTM [3,4] and SMV [17] never reclaim versions that may still be needed, but an active writer may create an unbounded number of history nodes for a reader to traverse. Systems that revert to inevitability for long-running readers are of course fundamentally blocking: a reader cannot start until active writers get out of the way.…”

Section: Theorem 2 the Total Space Ts Consumed By History Lists Is Imentioning

confidence: 99%

See 1 more Smart Citation

Generic Multiversion STM

Lü

Scott

2013

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. Multiversion software transactional memory (STM) allows a transaction to read old values of a recently updated object, after which the transaction may serialize before transactions that committed earlier in physical time. This ability to "commit in the past" is particularly appealing for long-running read-only transactions, which may otherwise starve in many STM systems, because short-running peers modify data out from under them before they have a chance to finish.Most previous approaches to multiversioning have been designed as an integral part of some larger STM system, and have assumed an object-oriented, garbage-collected language. We describe, instead, how multiversioning may be implemented on top of an almost arbitrary "wordbased" STM system. To the best of our knowledge, ours is the first work (for any kind of STM) to combine bounded space consumption with guaranteed wait freedom for read-only transactions (in the form presented here, it may require writers to be blocking). We make no assumptions about data or metadata layout, though we do require that the base system provide a hash function with certain ordering properties. We neither require nor interfere with automatic garbage collection. Privatization safety can be ensured-without compromising wait freedom for readers-either by forcing privatizing writers to wait for all extant readers or by requiring that programmers explicitly identify the data being privatized.

show abstract

Section: Theorem 2 the Total Space Ts Consumed By History Lists Is Imentioning

confidence: 99%

“…More recently, Perelman et al demonstrated, in their SMV system [17], how to eliminate explicit deletion: they distinguish between hard and weak references to an object version v, and arrange for the last hard reference to become unreachable once no running transaction has a start time earlier than that of the transaction that overwrote v.…”

Section: Introductionmentioning

confidence: 99%

Generic Multiversion STM

Lü

Scott

2013

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…Another approach for garbage collection was presented in our selective multi-versioning (SMV) STM [15]. SMV keeps a variable number of old versions, which reduces memory usage while ensuring read-only transactions can always commit.…”

Section: Space Optimalitymentioning

confidence: 99%

“…This optimistic approach inevitably leads to aborting transactions in some cases, such as when data dependencies introduce inconsistencies. When many transactions contend on the same data objects, aborts may become frequent, causing a devastating effect on performance [2,15]. Therefore, reducing the number of aborts is an important challenge for STMs.…”

Section: Introductionmentioning

confidence: 99%

“…Note that this implies the STM cannot use invisible reads [6], an important technique for optimizing read-only transactions. We also note that if the UP GC requirement is omitted, then it is possible to implement an STM using invisible reads, as done in our companion paper [15], assuming there exists a garbage collection thread that sees the private ("invisible") memory of all transactions, such as the Java GC.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

On maintaining multiple versions in STM

Perelman

Fan

Keidar

2010

Proceedings of the 29th ACM SIGACT-SIGOPS Symposium on Principles of Distributed Computing

Self Cite

View full text Add to dashboard Cite

An effective way to reduce the number of aborts in software transactional memory (STM) is to keep multiple versions of transactional objects. In this paper, we study inherent properties of STMs that use multiple versions to guarantee successful commits of all read-only transactions.We first show that these STMs cannot be disjoint-access parallel. We then consider the problem of garbage collecting old object versions, and show that no STM can be optimal in the number of previous versions kept. Moreover, we show that garbage collecting useless versions is impossible in STMs that implement invisible reads. Finally, we present an STM algorithm using visible reads that efficiently garbage collects useless object versions.

show abstract

Efficient support for in‐place metadata in Java software transactional memory

Dias

Vale

Lourenço

2013

Concurrency and Computation

View full text Add to dashboard Cite

SUMMARY Software transactional memory (STM) algorithms associate metadata with the memory locations accessed during a transaction's lifetime. This metadata may be stored in an external table by resorting to a mapping function that associates the address of a memory cell with the table entry containing the corresponding metadata (out‐place or external strategy). Alternatively, the metadata may be stored adjacent to the associated memory cell by wrapping the cell and metadata together (in‐place strategy). The implementation techniques to support these two approaches are very different and each STM framework is usually biased towards one of them, only allowing the efficient implementation of STM algorithms which suit one of the approaches and inhibiting a fair comparison with STM algorithms suiting the other. In this paper, we introduce a technique to implement in‐place metadata that does not wrap memory cells, thus overcoming the bias and allowing STM algorithms to directly access the transactional metadata. The proposed technique is available as an extension to Deuce and enables the efficient implementation of a wide range of STM algorithms and their fair (unbiased) comparison in a common STM framework. We illustrate the benefits of our approach by analyzing its impact in two popular transactional memory algorithms with several transactional workloads, TL2 and multiversioning, each befitting out‐place and in‐place, respectively. Copyright © 2013 John Wiley & Sons, Ltd.

show abstract

SMV: Selective Multi-Versioning STM

Cited by 38 publications

References 29 publications

Generic Multiversion STM

Generic Multiversion STM

On maintaining multiple versions in STM

Efficient support for in‐place metadata in Java software transactional memory

Contact Info

Product

Resources

About