Clustered Checkpointing and Partial Rollbacks for Reducing Conflict Costs in STMs

Abstract

A Software Transactional Memory is a concurrency control mechanism that executes multiple concurrent, optimistic, lockfree, atomic transactions, thus alleviating many problems associated with conventional mutual exclusion primitives such as monitors and locks. With the advent of massive multi-cores, more transactions can be initiated concurrently, however resulting in an increase in the percentage of conflicting transactions. Each time a transaction conflicts, it imposes a significant cost on the system, originating from the need to abort and redo all the operations, including the costly shared memory read operations, thus making the overall system significantly heavy and impractical. We present an algorithm, Clustered Checkpointing and Partial Rollback (CCPR), for reducing the conflict costs of transactions in the face of increasing conflicts. The algorithm is based on intelligent checkpointing of transactions as they proceed, and, in case of conflict, rolling them back to a safe, consistent, intermediate checkpoint, thus reducing conflict costs. The intelligence of the algorithm lies in the fact that as conflicts decrease, the checkpointing costs go low, however, when conflicts increase, the checkpointing costs increase but are still pretty much less than the amount of savings obtained by the partial rollback of the conflicting transactions. We simulated several applications in the CCPR framework and found that it can result in as good as 17% reduction in the conflict costs originating from the need to redo all the shared memory read operations.

Transparent Support for Partial Rollback in Software Transactional Memories

“…Considering partial rollback in STM systems as the specific target, a few solutions have been proposed in [11][12][13]. Differently from what we present in this article, the proposal in [11] is limited to the management of partial rollback operations on shared data, thus not supporting rollback of thread-private data.…”

“…As a consequence, mutual consistency between shared and private data within the partial rollback scheme is demanded from the programmer, while our approach enforces full transparency. The proposals in [12,13] consist of an architectural specification of partial rollback supports, which has however not been implemented in any real environment, and has been evaluated only via simulation. Instead, we provide a real implementation within the TinySTM framework.…”

STMs in practice: Partial rollback vs pure abort mechanisms

“…In the work by Lupei, the partial rollback operation is based only on shared data that does not support local data which requires extra effort from the programmer in ensuring consistency. Gupta et al() give an STM algorithm that supports both shared and local data for partial rollback. Porfirio et al give another STM that supports both shared and local data.…”

“…In the work by Lupei, 5 the partial rollback operation is based only on shared data that does not support local data which requires extra effort from the programmer in ensuring consistency. Gupta et al 6,7 give an STM algorithm that supports both shared and local data for partial rollback.Porfirio et al 8 give another STM that supports both shared and local data. Our work is based on that of Gupta et al 6 We have presented the enhanced Automatic Checkpointing and Partial Rollback (CaPR+) algorithm and given its proof of Opacity, 9 a correctness criterion for STMs in our previous work.…”

Opacity proof for CaPR+ algorithm

“…In [5] the partial rollback operation is based only on shared data that does not support local data which requires extra effort from the programmer in ensuring consistency. [7] and [6] is an STM algorithm that supports both shared and local data for partial rollback. [12] is another STM that supports both shared and local data.…”