Steal-on-Abort: Improving Transactional Memory Performance through Dynamic Transaction Reordering

Abstract

International audienceIn transactional memory, aborted transactions reduce performance, and waste computing resources. Ideally, concurrent execution of transactions should be optimally ordered to minimise aborts, but such an ordering is often either complex, or unfeasible, to obtain. This paper introduces a new technique called steal-on-abort, which aims to improve transaction ordering at runtime. Suppose transactions A and B conflict, and B is aborted. In general it is difficult to predict this first conflict, but once observed, it is logical not to execute the two transactions concurrently again. In steal-on-abort, the aborted transaction B is stolen by its opponent transaction A, and queued behind A to prevent concurrent execution of A and B. Without steal-on-abort, transaction B would typically have been restarted immediately, and possibly had a repeat conflict with transaction A. Steal-on-abort requires no application-specific information, modification, or offline pre-processing. In this paper, it is evaluated using a sorted linked list, red-black tree, STAMP-vacation, and Lee-TM. The evaluation reveals steal-on-abort is highly effective at eliminating repeat conflicts, which reduces the amount of computing resources wasted, and significantly improves performance

On the impact of serializing contention management on STM performance

“…As they show, this approach can improve performance when workloads lack parallelism. Ansari et al [1] proposed steal-on-abort, a transaction scheduler that avoids wasted work by allowing transactions to "steal" conflicting transactions so that they execute serially.…”

“…1 The CAS operation of line 30 atomically writes 3 values: a code indicating that the transaction is aborted, the index of the winning thread 2 , and the timestamp of the winning transaction. To facilitate atomic update of these 3 values, they are packed within a single 64-bit word (see line 1).…”

Scheduling support for transactional memory contention management

“…Recently, scheduling-based TM contention-management has been proposed for increasing TM efficiency under high-contention [2,5,19]. However, only user-level schedulers have been considered.…”

“…This observation has led researchers to consider various user-level scheduling policies performing some variant of serialization, in which the thread running a loser transaction is moved to a wait queue until the winner transaction completes [2,5,19]. Such approaches, however, incur a high overhead for short transactions, because they replicate at the user level kernel-level scheduling operations and abstractions and because their implementation introduces additional user-kernel context switches.…”

“…Conflicts are thus traditionally resolved by consulting an STM-level contention manager. Consequently, the contention managers of these "conventional" TM implementations suffer from a lack of precision and often fail to ensure reasonable performance in high-contention workloads.Recently, scheduling-based TM contention-management has been proposed for increasing TM efficiency under high-contention [2,5,19]. However, only user-level schedulers have been considered.…”