future/HTMtable.tex

% future/HTMtable.tex
% SPDX-License-Identifier: CC-BY-SA-3.0

\begin{table*}
\centering
% \scriptsize
\small
\input{future/HTMtableColor}
\setlength{\tabcolsep}{4pt}\OneColumnHSpace{-.9in}
\ebresizewidth{
\begin{tabularx}{6.5in}{p{0.95in}cXcX}
\toprule
  &
    & \multicolumn{1}{c}{Locking} &
      & \multicolumn{1}{c}{Hardware Transactional Memory} \\
\midrule
  Basic Idea &
    & Allow only one thread at a time to access a given set of objects. &
      & Cause a given operation over a set of objects to execute atomically. \\
\midrule
  Scope &
    & \Pl Handles all operations. &
      & \Pl Handles revocable operations. \\
\addlinespace[4pt]
  &
    & &
      & \Mn Irrevocable operations force fallback (typically to locking). \\
\midrule
  Composability &
    & \Dw Limited by deadlock. &
      & \Dw Limited by irrevocable operations, transaction size,
        and deadlock (assuming lock-based fallback code). \\
\midrule
  Scalability \& Performance &
    & \Mn Data must be partitionable to avoid lock contention. &
      & \Mn Data must be partitionable to avoid conflicts. \\
\cmidrule{3-5}
  &
    & \Dw Partioning must typically be fixed at design time. &
      & \Pl Dynamic adjustment of partitioning carried out automatically down
        to cacheline boundaries. \\
\addlinespace[4pt]
  &
    & &
      & \Mn Partitioning required for fallbacks (less important for rare
        fallbacks). \\
\cmidrule{3-5}
  &
    & \Dw Locking primitives typically result in expensive cache misses
      and memory-barrier instructions. &
      & \Mn Transactions begin/end instructions typically do not result in cache
        misses, but do have memory-ordering and overhead consequences. \\
\cmidrule{3-5}
  &
    & \Pl Contention effects are focused on acquisition and release, so
      that the critical section runs at full speed. &
      & \Mn Contention aborts conflicting transactions, even if they have been
        running for a long time. \\
\cmidrule{3-5}
  &
    & \Pl Privatization operations are simple, intuitive, performant,
      and scalable. &
      & \Mn Privatized data contributes to transaction size. \\
\midrule
  Hardware Support &
    & \Pl Commodity hardware suffices. &
      & \Mn New hardware required (and is starting to become available). \\
\cmidrule{3-5}
  &
    & \Pl Performance is insensitive to cache-geometry details. &
      & \Mn Performance depends critically on cache geometry. \\
\midrule
  Software Support &
    & \Pl APIs exist, large body of code and experience, debuggers operate
      naturally. &
      & \Mn APIs emerging, little experience outside of DBMS, breakpoints
        mid-transaction can be problematic. \\
\midrule
  Interaction With Other Mechanisms &
    & \Pl Long experience of successful interaction. &
      & \Dw Just beginning investigation of interaction. \\
\midrule
  Practical Apps &
    & \Pl Yes. &
      & \Pl Yes. \\
\midrule
  Wide Applicability &
    & \Pl Yes. &
      & \Mn Jury still out. \\
\bottomrule
\end{tabularx}
}
\IfTwoColumn{
\caption{Comparison of Locking and HTM (\colorbox{plus}{Advantage},
  \colorbox{minus}{Disadvantage}, \colorbox{down}{Strong Disadvantage})}
}{
\caption{Comparison of Locking and HTM (\colorbox{plus}{Advantage},
  \colorbox{minus}{Disadvantage},
  \colorbox{down}{Strong} \colorbox{down}{Disadvantage})}
}
\label{tab:future:Comparison of Locking and HTM}
\end{table*}