Software Transactional Memory

Hi Folks,

There’d been nearly dramatic shift in computer industry not to build a bigger or faster processor but putting more cores in a single processor chip, by making it smaller in order to get better throughput. If we want to run our applications faster, we need to learn parallel programming which get use the cores concurrently. That increasingly influences ordinary programmers to become concurrent programmers. But concurrent programming is bit too hard. Today’s concurrent programming is heavily based on locks & condition variables which introduce variety of problems & trade-o in performance, scalability & software engineering.

Transactional Memory

Transactional Memory (TM) is a promising concept in simplifying shared memory multi-core programming. TM ensures the correctness & performance over conventional locking schemes by replacing critical sections from an atomic block. Transactions will be executed atomically with respect to shared memory while TM synchronizes between concurrent transactions. It helps programmers to focus on high-level synchronization while ignoring the low level implementation details. TM avoids problems that locks & condition variables have introduced like priority inversion, convoying, and deadlocks in concurrent programming. By implementing transactional semantics in software, STM offers flexibility for programmers in an architecture independent way.

Serial equivalence property(serializability) of transactions avoid many problems in concurrent systems. It preserves that the combined transactions which are separated in time, will produce the same eect as they had been performed one at a time. The key idea behind many STM systems is to ensure serializability.

When utilizing multi-cores in concurrent programming, nested transactions serves well where it can perform parallel actions in each level of transactions’ subtrees. Also the ability that sub-transactions can work independently as a set of nested transactions is potentially more robust in multi-core systems.

Motivation

There did exist important discussions in famous research debate on STM about it’s own issues which are not presented in lock based concurrent systems. The former research work identifies that accessing shared memory object outside a transaction & the way transaction uses it’s locks inside a transaction do lead to bottleneck in interaction with non-transactional codes. That shows it’s not clear how to interact with codes which can’t be wrapped inside an atomic block: transaction. In the presence of partial failures there was no guarantee that all transactions do make any progress which make doubts on general transaction semantics. But the latter research work clearly said that STM can still outperform sequential code using different hardware configurations & workloads as benchmarks which cleared many doubts. They’ve clearly motivated further researches in the eld by increasing STM performance from using methods like manual instrumentation & transparent privatization etc. 

As TM heavily based on atomicity, any model implemented using that, should care more on strengthen the atomicity. While many Hardware Transactional Memory (HTM) systems provide strong atomicity, the researchers did pay their views to achieve it in STM as well.

Many STM systems detect confliicts by treating non-transactional code as short transactions to increase performance. Also researchers suggest various methods that can be used dynamically to increase STM performance. But there’s a strong believe that Hybrid Transactional Memory (HyTM) which combines HTM & STM will be the strong candidate in boosting overall performance.

Leave a comment