| % future/HTMtable.tex |
| % SPDX-License-Identifier: CC-BY-SA-3.0 |
| |
| \begin{table*}[p] |
| \centering |
| % \scriptsize |
| \small |
| \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*} |