Software transactional memory for dynamic-sized data structures

Abstract

We propose a new form of software transactional memory (STM) designed to support dynamic-sized data structures, and we describe a novel non-blocking implementation. The non-blocking property we consider is obstruction-~eedom.Obstruction-freedom is weaker than lock-freedom; as a result, it admits substantially simpler and more efficient implementations. A novel feature of our obstruction-free STM implementation is its use of modular contention managers to ensure progress in practice. We illustrate the utility of our dynamic STM with a straightforward implementation of an obstruction-free red-black tree, thereby demonstrating a sophisticated non-blocking dynamic data structure that would be difficult to implement by other means. We also present the results of simple preliminary performance experiments that demonstrate that an "early release" feature of our STM is useful for reducing contention, and that our STM lends itself to the effective use of modular contention managers.

Conflict Detection and Validation Strategies for Software Transactional Memory

“…To first approximation, its metadata organization ( Figure 1) resembles that of DSTM [11], but with what the latter calls a "Locator" merged into the newest copy of the data. Detailed description can be found in a previous paper [19]; we survey the highlights here.…”

“…The conflict counter is a useful improvement over visible readers in systems like DSTM [11] and SXM [5], where visible readers require the installation of a new Locator and thus are very expensive. Unfortunately, every update of a reader counter will invalidate the counter in every other reader's cache, leading to cache misses at commit time even when there are no writers.…”

“…The red-black tree is a balanced binary tree of values in the range 0..65535. The linked lists hold values from 0..255; one list uses early release [11] to avoid false conflicts; the other does not.…”

“…In ASTM, we adaptively switch from DSTM-style eager acquire [11] to OSTMstyle lazy acquire [2,3]. This permits some dynamic determination of how and when transactions should validate, but it is not as nuanced as mixed invalidation and does not avoid unnecessary validation.…”

Transactional Monitors for Concurrent Objects

“…Recognition of these issues has prompted a number of research efforts aimed at higher-level abstract notions of concurrency that omit any definition based on mutualexclusion locks [25,24,20,19]. In this paper, we propose transactional monitors as an alternative to mutual exclusion for object-oriented programming languages.…”