[PATCH -perfbook 2/3] defer, together: Group consecutive QQzs

[Akira Yokosawa <akiyks@gmail.com>]

These consecutive pairs of plain QQzs should be grouped by the
\QuickQuizSeries{ ... } construct.

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
 defer/rcuusage.tex   | 14 ++++++++------
 together/seqlock.tex | 14 ++++++++------
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/defer/rcuusage.tex b/defer/rcuusage.tex
index 2fb517c2..7a624e4c 100644
--- a/defer/rcuusage.tex
+++ b/defer/rcuusage.tex
@@ -506,13 +506,14 @@ run concurrently with \co{do_maint()} to complete, and finally
 \clnref{toquick} sets the \co{be_careful} flag back to \co{false}.
 \end{fcvref}
 
-\QuickQuiz{
+\QuickQuizSeries{%
+\QuickQuizB{
 	What is the point of the second call to \co{synchronize_rcu()}
 	in function
 	\co{maint()} in \cref{lst:defer:Phased State Change for Maintenance Operations}?
 	Isn't it OK for any \co{cco()} invocations in the clean-up
 	phase to invoke either \co{cco_carefully()} or \co{cco_quickly()}?
-}\QuickQuizAnswer{
+}\QuickQuizAnswerB{
 	The problem is that there is no ordering between the \co{cco()}
 	function's load from \co{be_careful} and any memory loads
 	executed by the \co{cco_quickly()} function.
@@ -525,13 +526,13 @@ run concurrently with \co{do_maint()} to complete, and finally
 	\co{READ_ONCE()} to \co{smp_load_acquire()} and the
 	\co{WRITE_ONCE()} to \co{smp_store_release()}, thus restoring
 	the needed ordering.
-}\QuickQuizEnd
+}\QuickQuizEndB
 
-\QuickQuiz{
+\QuickQuizE{
 	How can you be sure that the code shown in
 	\co{maint()} in \cref{lst:defer:Phased State Change for Maintenance Operations}
 	really works?\@
-}\QuickQuizAnswer{
+}\QuickQuizAnswerE{
 	By one popular school of thought, you cannot.
 
 	But in this case, those willing to jump ahead to
@@ -543,7 +544,8 @@ run concurrently with \co{do_maint()} to complete, and finally
 	\path{C-RCU-phased-state-change-2.litmus}).
 	These tests could be argued to demonstrate that this code
 	and a variant of it really do work.
-}\QuickQuizEnd
+}\QuickQuizEndE
+}% End of \QuickQuizSeries
 
 Phased state change allows frequent operations to use light-weight
 checks, without the need for expensive lock acquisitions or atomic
diff --git a/together/seqlock.tex b/together/seqlock.tex
index b8acbe3d..42eb8faa 100644
--- a/together/seqlock.tex
+++ b/together/seqlock.tex
@@ -221,11 +221,12 @@ Any reader succeeding in looking up the new name is guaranteed that
 any subsequent lookup of the old name will fail, perhaps after a series
 of retries.
 
-\QuickQuiz{
+\QuickQuizSeries{%
+\QuickQuizB{
 	Is it possible to write-acquire the sequence lock on
 	the new element before it is inserted instead of acquiring
 	that of the old element before it is removed?
-}\QuickQuizAnswer{
+}\QuickQuizAnswerB{
 	Yes, and the details are left as an exercise to the reader.
 
 	The term \emph{tombstone} is sometimes used to refer to the
@@ -233,11 +234,11 @@ of retries.
 	Similarly, the term \emph{birthstone} is sometimes used to refer
 	to the element with the new name while its sequence lock is
 	still held.
-}\QuickQuizEnd
+}\QuickQuizEndB
 
-\QuickQuiz{
+\QuickQuizE{
 	Is it possible to avoid the global lock?
-}\QuickQuizAnswer{
+}\QuickQuizAnswerE{
 	Yes, and one way to do this would be to use per-hash-chain locks.
 	The updater could acquire lock(s) corresponding to both the old
 	and the new element, acquiring them in address order.
@@ -247,7 +248,8 @@ of retries.
 	This complexity can be worthwhile if rename operations are
 	frequent, and of course can allow rename operations to execute
 	concurrently.
-}\QuickQuizEnd
+}\QuickQuizEndE
+}% End of \QuickQuizSeries
 
 It is of course possible to instead implement this procedure somewhat
 more efficiently using simple flags.
-- 
2.17.1