A pinboard by
this curator

Ph.D. Student, University of Rochester


This work proposes that a counter-intuitive hardware instruction should be included on future CPU processors. Prior CPU processors have implemented a functionality called "hardware transactional memory." Hardware transactional memory, or HTM, gives a program the ability to make a series of changes (a "transaction") while hiding intermediate steps, preventing its scratch work from becoming visible. If anyone else tries to see this scratch work, the attempt is aborted, leaving the global state unchanged (the program can then retry).

Our proposal argues that an always-abort HTM functionality is useful. A program using always-abort HTM (AAHTM) expects that, no matter what, the global state will remain unchanged after the transaction. This idea is useful because we can use AAHTM to "warm-up" the hardware before actually executing the real attempt. Since we can use AAHTM when it would be otherwise unsafe to execute code, and we can use it when a program would otherwise be waiting, we can use the functionality to accelerate a large class of programs. Notably, we are able to accelerate older versions of database software by up to 2.5x, and can accelerate modern matrix libraries by 15%.


Hardware extensions to make lazy subscription safe

Abstract: Transactional Lock Elision (TLE) uses Hardware Transactional Memory (HTM) to execute unmodified critical sections concurrently, even if they are protected by the same lock. To ensure correctness, the transactions used to execute these critical sections "subscribe" to the lock by reading it and checking that it is available. A recent paper proposed using the tempting "lazy subscription" optimization for a similar technique in a different context, namely transactional systems that use a single global lock (SGL) to protect all transactional data. We identify several pitfalls that show that lazy subscription \emph{is not safe} for TLE because unmodified critical sections executing before subscribing to the lock may behave incorrectly in a number of subtle ways. We also show that recently proposed compiler support for modifying transaction code to ensure subscription occurs before any incorrect behavior could manifest is not sufficient to avoid all of the pitfalls we identify. We further argue that extending such compiler support to avoid all pitfalls would add substantial complexity and would usually limit the extent to which subscription can be deferred, undermining the effectiveness of the optimization. Hardware extensions suggested in the recent proposal also do not address all of the pitfalls we identify. In this extended version of our WTTM 2014 paper, we describe hardware extensions that make lazy subscription safe, both for SGL-based transactional systems and for TLE, without the need for special compiler support. We also explain how nontransactional loads can be exploited, if available, to further enhance the effectiveness of lazy subscription.

Pub.: 23 Jul '14, Pinned: 29 Jun '17