Pitfalls of lazy subscriptionJuly 2014
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 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. A longer version of this
paper proposes hardware extensions that make lazy subscription
safe, both for SGL-based transactional systems and for TLE, without
the need for special compiler support.
Authors: Dave Dice, Tim Harris, Alex Kogan, Yossi Lev, Mark Moir
Venue: 6th Workshop on the Theory of Transactional Memory (WTTM 2014)