  State-of-the-art \emph{software transactional memory (STM)} implementations
achieve good performance by carefully avoiding the overhead of
\emph{incremental validation} (i.e., re-reading previously read data items to
avoid inconsistency) while still providing \emph{progressiveness} (allowing
transactional aborts only due to \emph{data conflicts}). Hardware transactional
memory (HTM) implementations promise even better performance, but offer no
progress guarantees. Thus, they must be combined with STMs, leading to
\emph{hybrid} TMs (HyTMs) in which hardware transactions must be
\emph{instrumented} (i.e., access metadata) to detect contention with software
transactions.
  We show that, unlike in progressive STMs, software transactions in
progressive HyTMs cannot avoid incremental validation. In fact, this result
holds even if hardware transactions can \emph{read} metadata
\emph{non-speculatively}. We then present \emph{opaque} HyTM algorithms
providing \emph{progressiveness for a subset of transactions} that are optimal
in terms of hardware instrumentation. We explore the concurrency vs. hardware
instrumentation vs. software validation trade-offs for these algorithms. Our
experiments with Intel and IBM POWER8 HTMs seem to suggest that (i) the
\emph{cost of concurrency} also exists in practice, (ii) it is important to
implement HyTMs that provide progressiveness for a maximal set of transactions
without incurring high hardware instrumentation overhead or using global
contending bottlenecks and (iii) there is no easy way to derive more efficient
HyTMs by taking advantage of non-speculative accesses within hardware.
