  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.
