Supporting Time-Based QoS Requirements in Software Transactional Memory

Abstract

Software transactional memory (STM) is an optimistic concurrency control mechanism that simplifies parallel programming. However, there has been little interest in its applicability to reactive applications in which there is a required response time for certain operations. We propose supporting such applications by allowing programmers to associate time with atomic blocks in the form of deadlines and quality-of-service (QoS) requirements. Based on statistics of past executions, we adjust the execution mode of transactions by decreasing the level of optimism as the deadline approaches. In the presence of concurrent deadlines, we propose different conflict resolution policies. Execution mode switching mechanisms allow the meeting of multiple deadlines in a consistent manner, with potential QoS degradations being split fairly among several threads as contention increases, and avoiding starvation. Our implementation consists of extensions to an STM runtime that allow gathering statistics and switching execution modes. We also propose novel contention managers adapted to transactional workloads subject to deadlines. The experimental evaluation shows that our approaches significantly improve the likelihood of a transaction meeting its deadline and QoS requirement, even in cases where progress is hampered by conflicts and other concurrent transactions with deadlines.

Preemptive Software Transactional Memory

“…The only work we are aware of which discriminates between transaction priorities in TM systems is the one in [13]. Here the authors cope with quality of service in STM applications, and introduce an approach where transactions that are subject to deadlines, and experience abort retries due to conflicts, tend to execute more conservatively (e.g.…”

“…More in detail, when a transaction has already been started, the longer the length of the time interval for reaching the commit phase, the higher the likelihood of conflict materialization with some concurrent transaction. Specifically, delaying the finalization of an already started transaction-because of a context switch off the CPU-leads to a stretch of the so-called transaction vulnerability window [13], which in turn may lead to an increase of the likelihood of transaction abort, a phenomenon adverse to performance. Keeping the already started transactions as hot records within the active list, and favoring them over the cold transactions kept by the standing list, exactly contrasts the stretch of the vulnerability window.…”