Composing Relaxed Transactions

Abstract

Abstract-As the classic transactional abstraction is sometimes considered too restrictive in leveraging parallelism, a lot of work has been devoted to devising relaxed transactional models with the goal of improving concurrency. Nevertheless, the quest for improving concurrency has somehow led to neglect one of the most appealing aspects of transactions: software composition, namely, the ability to develop pieces of software independently and compose them into applications that behave correctly in the face of concurrency. Indeed, a closer look at relaxed transactional models reveals that they do jeopardize composition, raising the fundamental question whether it is at all possible to devise such models while preserving composition. This paper shows that the answer is positive.We present outheritance, a necessary and sufficient condition for a (potentially relaxed) transactional memory to support composition. Basically, outheritance requires child transactions to pass their conflict information to their parent transaction, which in turn maintains this information until commit time. Concrete instantiations of this idea have been used before, classic transactions being the most prevalent example, but we believe to be the first to capture this as a general principle as well as to prove that it is, strictly speaking, equivalent to ensuring composition.We illustrate the benefits of outheritance using elastic transactions and show how they can satisfy outheritance and provide composition without hampering concurrency. We leverage this to present a new (transactional) Java package, a composable alternative to the concurrency package of the JDK, and evaluate efficiency through an implementation that speeds up state of the art software transactional memory implementations (TL2, LSA, SwissTM) by almost a factor of 3.

Nesting and composition in transactional data structure libraries

“…val ← next node in parentQ ▷ stays in parentQ 11: if val = ⊥ 12: val ← childQ.deq() ▷ Removed from childQ return val 13: procedure migrate 14: parentQ.appendAll(childQ) 15: procedure validate return true 16: Skiplist 17: sharedSkiplist ▷ Shared among all threads 18: parentReadSet, parentWriteSet ▷ Thread local 19: childReadSet, childWriteSet ▷ Thread local 20: procedure nGet(key) 21: add key to childReadSet 22: if key ∈ childWriteSet 23: return value from childWriteSet 24: else if key ∈ parentWriteSet 25: return value from parentWriteSet 26: else if key ∈ sharedSkiplist 27: return value from sharedSkiplist 28: return ⊥ 29: procedure nPut(key,value) 30: add key to childWriteSet 31: procedure validate 32: for each obj in childReadSet do 33: if obj.version > parent version 34: abort 35: procedure migrate 36: merge childWriteSet into parentWriteSet 37: merge childReadSet into parentReadSet Algorithm 4 Potential deadlock with nesting…”

Lock-Free Transactional Transformation for Linked Data Structures

“…Other STM variants, such open nested transactions [35], support a more relaxed transaction model that leverages some semantic knowledge based on programmers' input. The relaxation of STM systems and its implication on composability have been studied by Gramoli et al [13]. The work by Golan-Gueta et al [12] applies commutativity specifications obtained from programmers' input to inferring locks for abstract data types.…”

Lock-free Transactions without Rollbacks for Linked Data Structures

“…Other STM variants, such open nested transactions [32] support a more relaxed transaction model that leverages some semantic knowledge based on programmers' input. The relaxation of STM systems and its implication on composability have been studied by Gramoli et al [13]. The work by Golan-Gueta et al [12] applies commutativity specification obtained from programmers' input to inferring locks for abstract data types.…”

“…Because of such hazards, users are often forced to fall back to locking and even coarse-grained locking, which has a negative impact on performance and annihilates the non-blocking progress guarantees provided by some concurrent containers. The problem of implementing high-performance transac-tional data structures 4 is important and has recently gained much attention [2,11,12,13,19,21,26]. We refer to a transaction as sequence of linearizable operations on a concurrent data structure.…”