1 files changed, 32 insertions, 22 deletions

diff --git a/chapters/beyond-dsp.tex b/chapters/beyond-dsp.tex
index 7632261..fcd29b5 100644
--- a/chapters/beyond-dsp.tex
+++ b/chapters/beyond-dsp.tex
@@ -1955,28 +1955,6 @@ compress redundant data.
 
 \subsection{Concurrency}
 
-We also tested the preliminary concurrency support described in
-Section~\ref{ssec:dyn-concurrency}, using IRS as our test case, with our
-dynamization configured with $N_B = 1200$, $s=8$, and the tiering layout
-policy. Note that IRS only supports tagging, as it isn't invertible even
-under the IDSP model, and our current concurrency implementation only
-supports deletes with tombstones, so we eschewed deletes entirely for
-this test.
-
-In this benchmark, we used a single thread to insert records
-into the structure at a constant rate, while we deployed a variable
-number of additional threads that continuously issued sampling queries
-against the structure. We used an AGG B+tree as our baseline. Note
-that, to accurately maintain the aggregate weight counts as records
-are inserted, it is necessary that each operation obtain a lock on
-the root node of the tree~\cite{zhao22}.  This makes this situation
-a good use-case for the automatic concurrency support provided by our
-framework. Figure~\ref{fig:irs-concurrency} shows the results of this
-benchmark for various numbers of concurrency query threads. As can be seen,
-our framework supports a stable update throughput up to 32 query threads,
-whereas the AGG B+tree suffers from contention for the mutex and sees
-its performance degrade as the number of threads increases.
-
 \begin{figure}
     \centering
 	%\vspace{-2mm}
@@ -1987,6 +1965,38 @@ its performance degrade as the number of threads increases.
 	%\vspace{-2mm}
 \end{figure}
 
+We also tested the preliminary concurrency support described in
+Section~\ref{ssec:dyn-concurrency}, using IRS as our test case, with our
+dynamization configured with $N_B = 1200$, $s=8$, and the tiering layout
+policy. Note that IRS only supports tagging, as it isn't invertible even
+under the IDSP model, and our current concurrency implementation only
+supports deletes with tombstones, so we eschewed deletes entirely for
+this test.
+
+In this benchmark, we used a single thread to insert records into the
+structure at a constant rate, while we deployed a variable number of
+additional threads that continuously issued sampling queries against
+the structure. We used an AGG B+tree as our baseline. Note that,
+to accurately maintain the aggregate weight counts as records are
+inserted, it is necessary that each operation obtain a lock on the
+root node of the tree~\cite{zhao22}.  This makes this situation a
+good use-case for the automatic concurrency support provided by our
+framework. Figure~\ref{fig:irs-concurrency} shows the results of this
+benchmark for various numbers of concurrency query threads. As can be
+seen, our framework supports a stable update throughput up to 32 query
+threads, whereas the AGG B+tree suffers from contention for the mutex
+and sees its performance degrade as the number of threads increases. The
+framework is able to achieve this because queries are processed mostly
+independently from reconstructions due to the multi-versioning of the
+structure. Thus, a query can simply maintain a static view on a set
+of data within the dynamized structure for as long as it likes, while
+inserts can freely proceed. Because our implementation only maintains a
+limited number of structure versions, it is possible for long-running
+queries to slow down inserts, which will eventually be blocked until
+the query releases the version it is using, but this is a function of
+the query type itself, not the number of queries running or the number
+of client threads issuing queries.
+
 \section{Conclusion}
 
 In this chapter, we sought to develop a set of tools for generalizing