NOrec

Dalessandro, Luke; Spear, Michael; Scott, Michael L.

doi:10.1145/1693453.1693464

Cited by 189 publications

(56 citation statements)

References 29 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The OPTIK pattern can be viewed as a transaction. OPTIK shares some common characteristics with traditional STM transactions, especially those that defer synchronization to the commit phase (e.g., [6,9,14]). First, they are both explicitly delimited (i.e., we know where the transaction begins and where it ends).…”

Section: The Optik Patternmentioning

confidence: 99%

Optimistic concurrency with OPTIK

GuerraouiRachid

TrigonakisVasileios

2016

SIGPLAN Not.

View full text Add to dashboard Cite

We introduce OPTIK, a new practical design pattern for designing and implementing fast and scalable concurrent data structures. OPTIK relies on the commonly-used technique of version numbers for detecting conflicting concurrent operations. We show how to implement the OPTIK pattern using the novel concept of OPTIK locks. These locks enable the use of version numbers for implementing very efficient optimistic concurrent data structures. Existing state-of-the-art lock-based data structures acquire the lock and then check for conflicts. In contrast, with OPTIK locks, we merge the lock acquisition with the detection of conflicting concurrency in a single atomic step, similarly to lock-free algorithms. We illustrate the power of our OPTIK pattern and its implementation by introducing four new algorithms and by optimizing four state-of-the-art algorithms for linked lists, skip lists, hash tables, and queues. Our results show that concurrent data structures built using OPTIK are more scalable than the state of the art.

show abstract

Section: The Optik Patternmentioning

confidence: 99%

Optimistic concurrency with OPTIK

GuerraouiRachid

TrigonakisVasileios

2016

SIGPLAN Not.

View full text Add to dashboard Cite

show abstract

“…Figure 2 (top) present results for a read-heavy test with sum, lookup, and update (insert and delete) operations in a ratio of 1:79:20. We compare the throughput (transactions/second) of LLT, GMV+, and two variants of the simpler NOrec algorithm [5]. Because NOrec serializes transaction write-back using a global lock, it supports a trivial implementation of inevitability (irrevocability).…”

Section: Performance Of a Proof-of-concept Implementationmentioning

confidence: 99%

“…This "early serialization" resembles that of mainstream systems like TL2 [6], but multiversioning avoids the need to abort and restart read-only transactions that attempt to read a location that has changed since the transaction's start time. Early serialization stands in contrast to systems like RingSTM [23] and NOrec [5], which serialize readers at commit time, and to systems like TinySTM [22] and SwissTM [7], which dynamically update their "start time" in response to commits in other transactions, and may therefore serialize at some internal transactional read.…”

mentioning

confidence: 99%

Generic Multiversion STM

Lü

Scott

2013

Lecture Notes in Computer Science

Self Cite

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

“…In [4] Shavit and Touitou allow a transaction to see an inconsistent state but from that point on the operation is considered a zombie, and will not complete successfully. Most modern STM algorithms [5][6][7][8] conservatively abort a transaction as soon as the possibility of inconsistency is detected. Others [5,7,9] force consistency by having even read-only operations check locks and global clocks or by maintaining multiple versions per address.…”

Section: Introduction and Related Workmentioning

confidence: 99%

“…Each and every access of a transaction to a shared variable or object must be instrumented in some way or another. This instrumentation is a major source of modern STM overhead, which in some cases can be reduced by algorithms such as the NORec STM [6]. These schemes avoid per object meta data, which reduces instrumentation overhead at the price of reduced scalability.…”

Section: Introduction and Related Workmentioning

confidence: 99%

Towards Consistency Oblivious Programming

Afek

Avni

Shavit

2011

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract.It is well known that guaranteeing program consistency when accessing shared data comes at the price of degraded performance and scalability. This paper initiates the investigation of consistency oblivious programming (COP). In COP, sections of concurrent code that meet certain criteria are executed without checking for consistency. However, checkpoints are added before any shared data modification to verify the algorithm was on the right track, and if not, it is re-executed in a more conservative and expensive consistent way. We show empirically that the COP approach can enhance a software transactional memory (STM) framework to deliver more efficient concurrent data structures from serial source code. In some cases the COP code delivers performance comparable to that of more complex fine-grained structures.

show abstract

NOrec

Cited by 189 publications

References 29 publications

Optimistic concurrency with OPTIK

Optimistic concurrency with OPTIK

Generic Multiversion STM

Towards Consistency Oblivious Programming

Contact Info

Product

Resources

About