Some challenges facing Transactional Memory

Evaluating Transactional Memory: TM’s advantages with respect to locks can be categorized roughly into to two categories: those relating to performance (optimistic execution and fine-grain synchronization) and those relating to programmability (no need to associate a synchronization variable to critical sections, natural composition, fault tolerance, and avoiding priority inversion). To date much of the technical evaluation of TM has focused on the former, with very little attempt (to our knowledge) to quantify the impact of the latter. We believe that the importance of the latter needs to be understood because much of the performance benefits of TM can be achieved using a much more straight-forward, evolutionary technique: Speculative Lock Elision (SLE). SLE is a hardware technique for performing an optimistic execution of conventional (e.g., locked) critical sections with fine-grain conflict detection. In the presence of modest sized critical sections (≤10k dynamic instructions) and modest contention, SLE will match or exceed the performance of any Hardware TM (HTM) system and outperform Software TM (STM) systems. Most importantly, however, SLE is very straight-forward to implement—it is already shipping in the Azul Systems Java Appliance— as unbounded “transactions” need not be supported and no source code changes are required for its use. With the challenges remaining in how TM should be cleanly and efficiently architected (some of which we discuss below) and the significant software investment that will be required to enable its widespread adoption, it is import to understand the true programmability benefits of TM. This will require the involvment of software engineering experts and studies of programmer productivity. In such efforts, we suggest that in addition to comparing TM against locks, such work also considers SLE as another benchmark against which TMs benefits must be demonstrated.