Refereeing Conflicts in Transactional Memory Systems

In the search for high performance, most transactional memory (TM) systems execute atomic blocks concurrently and must thus be prepared for data conflicts. These conflicts must be detected and the system must choose a policy in terms of when and how to manage the resulting contention. Conflict detection essentially determines when the conflict manager is invoked, which can be dealt with eagerly (when the transaction reads/writes the location), lazily at commit time, or somewhere in between. In this paper, we analyze the interaction between conflict detection and contention manager heuristics. We show that this has a significant impact on exploitation of available parallelism and overall throughput. First, our analysis across a wide range of applications reveals that simply stalling before arbitrating helps side-step conflicts and avoid making the wrong decision. HTM systems that don't support stalling after detecting a conflict seem to be prone to cascaded aborts and livelock. Second, we show that the time at which the contention manager is invoked is an important policy decision: lazy systems are inherently more robust while eager systems seem prone to pathologies, sometimes introduced by the contention manager itself. Finally, we evaluate a \textit{mixed} conflict detection mode that combines the best of eager and lazy. It resolves write-write conflicts early, saving wasted work, and read-write conflicts lazily, allowing the reader to commit/serialize prior to the writer while executing concurrently