Transactional Locking II

SMV: Selective Multi-Versioning STM

“…Of these, SMV is most closely related to TL2 [11], from which we borrow the ideas of invisible reads, commit-time locking of updated objects, and a global version clock for consistency checking. In a way, SMV can be seen as a multi-versioned extension of TL2.…”

“…Like TL2 [11] and LSA [25], SMV uses a global version clock to detect conflicts. Each transaction reads the clock when it begins, and update transactions increment the clock upon commit.…”

“…Each object is tagged with the version clock of the transaction that wrote it. Though the global version clock is a contention-point, many practical optimizations were introduced to reduce the overhead associated with it [11,27]. Such optimizations are orthogonal to our work, and are therefore beyond the scope of this paper.…”

“…This way, multiple versions have the potential to improve the performance of singleversioned STMs [11][12][13]18], which, as we show below, might waste as much as 80% of their time because of aborts in benchmarks with many read-only transactions.…”

“…We implement SMV in Java 2 and study its behavior using STMBench7 [15] as well as a Java port of Vacation [8]. We compare SMV to a TL2-style algorithm -a single-versioned STM whose basic operation is like that of TL2 [11]; and to a k-versioned variant of the same algorithm, which keeps k previous versions per object, similarly to LSA [25].…”