future/HTMtable.tex

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

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