Re: [PATCH] Convert code snippets to 'listing' env (howto, toolsoftrade, count)

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

On Wed, Oct 11, 2017 at 07:40:14AM +0900, Akira Yokosawa wrote:
> >From d3f43d97fdbcbe68b6e5936b8d94c50b78bfeaaf Mon Sep 17 00:00:00 2001
> From: Akira Yokosawa <akiyks@gmail.com>
> Date: Mon, 10 Oct 2017 22:18:17 +0900
> Subject: [PATCH] Convert code snippets to 'listing' env (howto, toolsoftrade, count)
> 
> Also fix a typo referring table by "Figure" in count.tex.
> 
> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> ---
> Hi Paul,
> 
> Looks like we have some time to do the conversion to "listing" environments
> before the upcoming release.
> 
> This is the 1st round of the conversion.

Looks like a good time, thank you!  Queued and pushed.

							Thanx, Paul

>             Thanks, Akira
> --
>  count/count.tex               | 276 +++++++++++++++++++++---------------------
>  defer/rcuexercises.tex        |   2 +-
>  howto/howto.tex               |  20 +--
>  owned/owned.tex               |  28 ++---
>  together/applyrcu.tex         |  16 +--
>  toolsoftrade/toolsoftrade.tex | 140 ++++++++++-----------
>  6 files changed, 241 insertions(+), 241 deletions(-)
> 
> diff --git a/count/count.tex b/count/count.tex
> index a213558..9638971 100644
> --- a/count/count.tex
> +++ b/count/count.tex
> @@ -165,7 +165,7 @@ are more appropriate for advanced students.
>  \section{Why Isn't Concurrent Counting Trivial?}
>  \label{sec:count:Why Isn't Concurrent Counting Trivial?}
> 
> -\begin{figure}[bp]
> +\begin{listing}[bp]
>  { \scriptsize
>  \begin{verbbox}
>    1 long counter = 0;
> @@ -184,12 +184,12 @@ are more appropriate for advanced students.
>  \centering
>  \theverbbox
>  \caption{Just Count!}
> -\label{fig:count:Just Count!}
> -\end{figure}
> +\label{lst:count:Just Count!}
> +\end{listing}
> 
>  Let's start with something simple, for example, the straightforward
>  use of arithmetic shown in
> -Figure~\ref{fig:count:Just Count!} (\path{count_nonatomic.c}).
> +Listing~\ref{lst:count:Just Count!} (\path{count_nonatomic.c}).
>  Here, we have a counter on line~1, we increment it on line~5, and we
>  read out its value on line~10.
>  What could be simpler?
> @@ -242,7 +242,7 @@ accuracies far greater than 50\,\% are almost always necessary.
>  	Furthermore, proofs can have bugs just as easily as programs can!
>  } \QuickQuizEnd
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 atomic_t counter = ATOMIC_INIT(0);
> @@ -261,8 +261,8 @@ accuracies far greater than 50\,\% are almost always necessary.
>  \centering
>  \theverbbox
>  \caption{Just Count Atomically!}
> -\label{fig:count:Just Count Atomically!}
> -\end{figure}
> +\label{lst:count:Just Count Atomically!}
> +\end{listing}
> 
>  \begin{figure}[tb]
>  \centering
> @@ -273,7 +273,7 @@ accuracies far greater than 50\,\% are almost always necessary.
> 
>  The straightforward way to count accurately is to use atomic operations,
>  as shown in
> -Figure~\ref{fig:count:Just Count Atomically!} (\path{count_atomic.c}).
> +Listing~\ref{lst:count:Just Count Atomically!} (\path{count_atomic.c}).
>  Line~1 defines an atomic variable, line~5 atomically increments it, and
>  line~10 reads it out.
>  Because this is atomic, it keeps perfect count.
> @@ -491,7 +491,7 @@ thread (presumably cache aligned and padded to avoid false sharing).
>  	Section~\ref{sec:count:Per-Thread-Variable-Based Implementation}.
>  } \QuickQuizEnd
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 DEFINE_PER_THREAD(long, counter);
> @@ -515,11 +515,11 @@ thread (presumably cache aligned and padded to avoid false sharing).
>  \centering
>  \theverbbox
>  \caption{Array-Based Per-Thread Statistical Counters}
> -\label{fig:count:Array-Based Per-Thread Statistical Counters}
> -\end{figure}
> +\label{lst:count:Array-Based Per-Thread Statistical Counters}
> +\end{listing}
> 
>  Such an array can be wrapped into per-thread primitives, as shown in
> -Figure~\ref{fig:count:Array-Based Per-Thread Statistical Counters}
> +Listing~\ref{lst:count:Array-Based Per-Thread Statistical Counters}
>  (\path{count_stat.c}).
>  Line~1 defines an array containing a set of per-thread counters of
>  type \co{long} named, creatively enough, \co{counter}.
> @@ -559,7 +559,7 @@ normal loads suffice, and no special atomic instructions are required.
> 
>  \QuickQuiz{}
>  	How does the per-thread \co{counter} variable in
> -	Figure~\ref{fig:count:Array-Based Per-Thread Statistical Counters}
> +	Listing~\ref{lst:count:Array-Based Per-Thread Statistical Counters}
>  	get initialized?
>  \QuickQuizAnswer{
>  	The C standard specifies that the initial value of
> @@ -573,7 +573,7 @@ normal loads suffice, and no special atomic instructions are required.
> 
>  \QuickQuiz{}
>  	How is the code in
> -	Figure~\ref{fig:count:Array-Based Per-Thread Statistical Counters}
> +	Listing~\ref{lst:count:Array-Based Per-Thread Statistical Counters}
>  	supposed to permit more than one counter?
>  \QuickQuizAnswer{
>  	Indeed, this toy example does not support more than one counter.
> @@ -602,7 +602,7 @@ at the beginning of this chapter.
>  	and during that time, the counter could well be changing.
>  	This means that the value returned by
>  	\co{read_count()} in
> -	Figure~\ref{fig:count:Array-Based Per-Thread Statistical Counters}
> +	Listing~\ref{lst:count:Array-Based Per-Thread Statistical Counters}
>  	will not necessarily be exact.
>  	Assume that the counter is being incremented at rate
>  	$r$ counts per unit time, and that \co{read_count()}'s
> @@ -743,7 +743,7 @@ date, however, once updates cease, the global counter will eventually
>  converge on the true value---hence this approach qualifies as
>  eventually consistent.
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>   1 DEFINE_PER_THREAD(unsigned long, counter);
> @@ -802,11 +802,11 @@ eventually consistent.
>  \centering
>  \theverbbox
>  \caption{Array-Based Per-Thread Eventually Consistent Counters}
> -\label{fig:count:Array-Based Per-Thread Eventually Consistent Counters}
> -\end{figure}
> +\label{lst:count:Array-Based Per-Thread Eventually Consistent Counters}
> +\end{listing}
> 
>  The implementation is shown in
> -Figure~\ref{fig:count:Array-Based Per-Thread Eventually Consistent Counters}
> +Listing~\ref{lst:count:Array-Based Per-Thread Eventually Consistent Counters}
>  (\path{count_stat_eventual.c}).
>  Lines~1-2 show the per-thread variable and the global variable that
>  track the counter's value, and line three shows \co{stopflag}
> @@ -814,7 +814,7 @@ which is used to coordinate termination (for the case where we want
>  to terminate the program with an accurate counter value).
>  The \co{inc_count()} function shown on lines~5-9 is similar to its
>  counterpart in
> -Figure~\ref{fig:count:Array-Based Per-Thread Statistical Counters}.
> +Listing~\ref{lst:count:Array-Based Per-Thread Statistical Counters}.
>  The \co{read_count()} function shown on lines~11-14 simply returns the
>  value of the \co{global_count} variable.
> 
> @@ -834,7 +834,7 @@ comes at the cost of the additional thread running \co{eventual()}.
> 
>  \QuickQuiz{}
>  	Why doesn't \co{inc_count()} in
> -	Figure~\ref{fig:count:Array-Based Per-Thread Eventually Consistent Counters}
> +	Listing~\ref{lst:count:Array-Based Per-Thread Eventually Consistent Counters}
>  	need to use atomic instructions?
>  	After all, we now have multiple threads accessing the per-thread
>  	counters!
> @@ -872,7 +872,7 @@ comes at the cost of the additional thread running \co{eventual()}.
> 
>  \QuickQuiz{}
>  	Won't the single global thread in the function \co{eventual()} of
> -	Figure~\ref{fig:count:Array-Based Per-Thread Eventually Consistent Counters}
> +	Listing~\ref{lst:count:Array-Based Per-Thread Eventually Consistent Counters}
>  	be just as severe a bottleneck as a global lock would be?
>  \QuickQuizAnswer{
>  	In this case, no.
> @@ -883,7 +883,7 @@ comes at the cost of the additional thread running \co{eventual()}.
> 
>  \QuickQuiz{}
>  	Won't the estimate returned by \co{read_count()} in
> -	Figure~\ref{fig:count:Array-Based Per-Thread Eventually Consistent Counters}
> +	Listing~\ref{lst:count:Array-Based Per-Thread Eventually Consistent Counters}
>  	become increasingly
>  	inaccurate as the number of threads rises?
>  \QuickQuizAnswer{
> @@ -897,7 +897,7 @@ comes at the cost of the additional thread running \co{eventual()}.
> 
>  \QuickQuiz{}
>  	Given that in the eventually\-/consistent algorithm shown in
> -	Figure~\ref{fig:count:Array-Based Per-Thread Eventually Consistent Counters}
> +	Listing~\ref{lst:count:Array-Based Per-Thread Eventually Consistent Counters}
>  	both reads and updates have extremely low overhead
>  	and are extremely scalable, why would anyone bother with the
>  	implementation described in
> @@ -934,7 +934,7 @@ comes at the cost of the additional thread running \co{eventual()}.
>  \subsection{Per-Thread-Variable-Based Implementation}
>  \label{sec:count:Per-Thread-Variable-Based Implementation}
> 
> -\begin{figure}[tb]
> +\begin{listing}[tb]
>  { \scriptsize
>  \begin{verbbox}
>    1 long __thread counter = 0;
> @@ -984,13 +984,13 @@ comes at the cost of the additional thread running \co{eventual()}.
>  \centering
>  \theverbbox
>  \caption{Per-Thread Statistical Counters}
> -\label{fig:count:Per-Thread Statistical Counters}
> -\end{figure}
> +\label{lst:count:Per-Thread Statistical Counters}
> +\end{listing}
> 
>  Fortunately, \GCC\ provides an \co{__thread} storage class that provides
>  per-thread storage.
>  This can be used as shown in
> -Figure~\ref{fig:count:Per-Thread Statistical Counters} (\path{count_end.c})
> +Listing~\ref{lst:count:Per-Thread Statistical Counters} (\path{count_end.c})
>  to implement
>  a statistical counter that not only scales, but that also incurs little
>  or no performance penalty to incrementers compared to simple non-atomic
> @@ -1058,7 +1058,7 @@ Finally, line~22 returns the sum.
> 
>  \QuickQuiz{}
>  	Doesn't the check for \co{NULL} on line~19 of
> -	Figure~\ref{fig:count:Per-Thread Statistical Counters}
> +	Listing~\ref{lst:count:Per-Thread Statistical Counters}
>  	add extra branch mispredictions?
>  	Why not have a variable set permanently to zero, and point
>  	unused counter-pointers to that variable rather than setting
> @@ -1074,7 +1074,7 @@ Finally, line~22 returns the sum.
>  \QuickQuiz{}
>  	Why on earth do we need something as heavyweight as a \emph{lock}
>  	guarding the summation in the function \co{read_count()} in
> -	Figure~\ref{fig:count:Per-Thread Statistical Counters}?
> +	Listing~\ref{lst:count:Per-Thread Statistical Counters}?
>  \QuickQuizAnswer{
>  	Remember, when a thread exits, its per-thread variables disappear.
>  	Therefore, if we attempt to access a given thread's per-thread
> @@ -1105,7 +1105,7 @@ array to point to its per-thread \co{counter} variable.
>  \QuickQuiz{}
>  	Why on earth do we need to acquire the lock in
>  	\co{count_register_thread()} in
> -	Figure~\ref{fig:count:Per-Thread Statistical Counters}?
> +	Listing~\ref{lst:count:Per-Thread Statistical Counters}?
>  	It is a single properly aligned machine-word store to a location
>  	that no other thread is modifying, so it should be atomic anyway,
>  	right?
> @@ -1150,7 +1150,7 @@ variables vanish when that thread exits.
>  	accessible, even if the corresponding CPU is offline---even
>  	if the corresponding CPU never existed and never will exist.
> 
> -\begin{figure}[tb]
> +\begin{listing}[tb]
>  { \scriptsize
>  \begin{verbbox}
>    1 long __thread counter = 0;
> @@ -1196,12 +1196,12 @@ variables vanish when that thread exits.
>  \centering
>  \theverbbox
>  \caption{Per-Thread Statistical Counters With Lockless Summation}
> -\label{fig:count:Per-Thread Statistical Counters With Lockless Summation}
> -\end{figure}
> +\label{lst:count:Per-Thread Statistical Counters With Lockless Summation}
> +\end{listing}
> 
>  	One workaround is to ensure that each thread continues to exist
>  	until all threads are finished, as shown in
> -	Figure~\ref{fig:count:Per-Thread Statistical Counters With Lockless Summation}
> +	Listing~\ref{lst:count:Per-Thread Statistical Counters With Lockless Summation}
>  	(\path{count_tstat.c}).
>  	Analysis of this code is left as an exercise to the reader,
>  	however, please note that it does not fit well into the
> @@ -1388,7 +1388,7 @@ Section~\ref{sec:SMPdesign:Parallel Fastpath}.
>  \subsection{Simple Limit Counter Implementation}
>  \label{sec:count:Simple Limit Counter Implementation}
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 unsigned long __thread counter = 0;
> @@ -1403,8 +1403,8 @@ Section~\ref{sec:SMPdesign:Parallel Fastpath}.
>  \centering
>  \theverbbox
>  \caption{Simple Limit Counter Variables}
> -\label{fig:count:Simple Limit Counter Variables}
> -\end{figure}
> +\label{lst:count:Simple Limit Counter Variables}
> +\end{listing}
> 
>  \begin{figure}[tb]
>  \centering
> @@ -1413,7 +1413,7 @@ Section~\ref{sec:SMPdesign:Parallel Fastpath}.
>  \label{fig:count:Simple Limit Counter Variable Relationships}
>  \end{figure}
> 
> -Figure~\ref{fig:count:Simple Limit Counter Variables}
> +Listing~\ref{lst:count:Simple Limit Counter Variables}
>  shows both the per-thread and global variables used by this
>  implementation.
>  The per-thread \co{counter} and \co{countermax} variables are the
> @@ -1443,7 +1443,7 @@ spinlock guards all of the global variables, in other words, no thread
>  is permitted to access or modify any of the global variables unless it
>  has acquired \co{gblcnt_mutex}.
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 int add_count(unsigned long delta)
> @@ -1501,17 +1501,17 @@ has acquired \co{gblcnt_mutex}.
>  \centering
>  \theverbbox
>  \caption{Simple Limit Counter Add, Subtract, and Read}
> -\label{fig:count:Simple Limit Counter Add, Subtract, and Read}
> -\end{figure}
> +\label{lst:count:Simple Limit Counter Add, Subtract, and Read}
> +\end{listing}
> 
> -Figure~\ref{fig:count:Simple Limit Counter Add, Subtract, and Read}
> +Listing~\ref{lst:count:Simple Limit Counter Add, Subtract, and Read}
>  shows the \co{add_count()}, \co{sub_count()}, and \co{read_count()}
>  functions (\path{count_lim.c}).
> 
> 
>  \QuickQuiz{}
>  	Why does
> -	Figure~\ref{fig:count:Simple Limit Counter Add, Subtract, and Read}
> +	Listing~\ref{lst:count:Simple Limit Counter Add, Subtract, and Read}
>  	provide \co{add_count()} and \co{sub_count()} instead of the
>  	\co{inc_count()} and \co{dec_count()} interfaces show in
>  	Section~\ref{sec:count:Statistical Counters}?
> @@ -1531,7 +1531,7 @@ references only per-thread variables, and should not incur any cache misses.
> 
>  \QuickQuiz{}
>  	What is with the strange form of the condition on line~3 of
> -	Figure~\ref{fig:count:Simple Limit Counter Add, Subtract, and Read}?
> +	Listing~\ref{lst:count:Simple Limit Counter Add, Subtract, and Read}?
>  	Why not the following more intuitive form of the fastpath?
> 
>  	\vspace{5pt}
> @@ -1552,7 +1552,7 @@ references only per-thread variables, and should not incur any cache misses.
>  	Try the above formulation with \co{counter} equal to 10 and
>  	\co{delta} equal to \co{ULONG_MAX}.
>  	Then try it again with the code shown in
> -	Figure~\ref{fig:count:Simple Limit Counter Add, Subtract, and Read}.
> +	Listing~\ref{lst:count:Simple Limit Counter Add, Subtract, and Read}.
> 
>  	A good understanding of integer overflow will be required for
>  	the rest of this example, so if you have never dealt with
> @@ -1566,7 +1566,7 @@ If the test on line~3 fails, we must access global variables, and thus
>  must acquire \co{gblcnt_mutex} on line~7, which we release on line~11
>  in the failure case or on line~16 in the success case.
>  Line~8 invokes \co{globalize_count()}, shown in
> -Figure~\ref{fig:count:Simple Limit Counter Utility Functions},
> +Listing~\ref{lst:count:Simple Limit Counter Utility Functions},
>  which clears the thread-local variables, adjusting the global variables
>  as needed, thus simplifying global processing.
>  (But don't take \emph{my} word for it, try coding it yourself!)
> @@ -1581,7 +1581,7 @@ returns indicating failure.
>  Otherwise, we take the slowpath.
>  Line~14 adds \co{delta} to \co{globalcount}, and then
>  line~15 invokes \co{balance_count()} (shown in
> -Figure~\ref{fig:count:Simple Limit Counter Utility Functions})
> +Listing~\ref{lst:count:Simple Limit Counter Utility Functions})
>  in order to update both the global and the per-thread variables.
>  This call to \co{balance_count()}
>  will usually set this thread's \co{countermax} to re-enable the fastpath.
> @@ -1592,7 +1592,7 @@ line~17 returns indicating success.
>  \QuickQuiz{}
>  	Why does \co{globalize_count()} zero the per-thread variables,
>  	only to later call \co{balance_count()} to refill them in
> -	Figure~\ref{fig:count:Simple Limit Counter Add, Subtract, and Read}?
> +	Listing~\ref{lst:count:Simple Limit Counter Add, Subtract, and Read}?
>  	Why not just leave the per-thread variables non-zero?
>  \QuickQuizAnswer{
>  	That is in fact what an earlier version of this code did.
> @@ -1616,7 +1616,7 @@ Because the slowpath must access global state, line~26
>  acquires \co{gblcnt_mutex}, which is released either by line~29
>  (in case of failure) or by line~34 (in case of success).
>  Line~27 invokes \co{globalize_count()}, shown in
> -Figure~\ref{fig:count:Simple Limit Counter Utility Functions},
> +Listing~\ref{lst:count:Simple Limit Counter Utility Functions},
>  which again clears the thread-local variables, adjusting the global variables
>  as needed.
>  Line~28 checks to see if the counter can accommodate subtracting
> @@ -1626,7 +1626,7 @@ Line~28 checks to see if the counter can accommodate subtracting
>  \QuickQuiz{}
>  	Given that \co{globalreserve} counted against us in \co{add_count()},
>  	why doesn't it count for us in \co{sub_count()} in
> -	Figure~\ref{fig:count:Simple Limit Counter Add, Subtract, and Read}?
> +	Listing~\ref{lst:count:Simple Limit Counter Add, Subtract, and Read}?
>  \QuickQuizAnswer{
>  	The \co{globalreserve} variable tracks the sum of all threads'
>  	\co{countermax} variables.
> @@ -1641,7 +1641,7 @@ Line~28 checks to see if the counter can accommodate subtracting
> 
>  \QuickQuiz{}
>  	Suppose that one thread invokes \co{add_count()} shown in
> -	Figure~\ref{fig:count:Simple Limit Counter Add, Subtract, and Read},
> +	Listing~\ref{lst:count:Simple Limit Counter Add, Subtract, and Read},
>  	and then another thread invokes \co{sub_count()}.
>  	Won't \co{sub_count()} return failure even though the value of
>  	the counter is non-zero?
> @@ -1658,14 +1658,14 @@ If, on the other hand, line~28 finds that the counter \emph{can}
>  accommodate subtracting \co{delta}, we complete the slowpath.
>  Line~32 does the subtraction and then
>  line~33 invokes \co{balance_count()} (shown in
> -Figure~\ref{fig:count:Simple Limit Counter Utility Functions})
> +Listing~\ref{lst:count:Simple Limit Counter Utility Functions})
>  in order to update both global and per-thread variables
>  (hopefully re-enabling the fastpath).
>  Then line~34 releases \co{gblcnt_mutex}, and line~35 returns success.
> 
>  \QuickQuiz{}
>  	Why have both \co{add_count()} and \co{sub_count()} in
> -	Figure~\ref{fig:count:Simple Limit Counter Add, Subtract, and Read}?
> +	Listing~\ref{lst:count:Simple Limit Counter Add, Subtract, and Read}?
>  	Why not simply pass a negative number to \co{add_count()}?
>  \QuickQuizAnswer{
>  	Given that \co{add_count()} takes an \co{unsigned} \co{long}
> @@ -1686,7 +1686,7 @@ Line~44 initializes local variable \co{sum} to the value of
>  per-thread \co{counter} variables.
>  Line~49 then returns the sum.
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 static void globalize_count(void)
> @@ -1732,13 +1732,13 @@ Line~49 then returns the sum.
>  \centering
>  \theverbbox
>  \caption{Simple Limit Counter Utility Functions}
> -\label{fig:count:Simple Limit Counter Utility Functions}
> -\end{figure}
> +\label{lst:count:Simple Limit Counter Utility Functions}
> +\end{listing}
> 
> -Figure~\ref{fig:count:Simple Limit Counter Utility Functions}
> +Listing~\ref{lst:count:Simple Limit Counter Utility Functions}
>  shows a number of utility functions used by the \co{add_count()},
>  \co{sub_count()}, and \co{read_count()} primitives shown in
> -Figure~\ref{fig:count:Simple Limit Counter Add, Subtract, and Read}.
> +Listing~\ref{lst:count:Simple Limit Counter Add, Subtract, and Read}.
> 
>  Lines~1-7 show \co{globalize_count()}, which zeros the current thread's
>  per-thread counters, adjusting the global variables appropriately.
> @@ -1782,7 +1782,7 @@ Finally, in either case, line~18 makes the corresponding adjustment to
> 
>  \QuickQuiz{}
>  	Why set \co{counter} to \co{countermax / 2} in line~15 of
> -	Figure~\ref{fig:count:Simple Limit Counter Utility Functions}?
> +	Listing~\ref{lst:count:Simple Limit Counter Utility Functions}?
>  	Wouldn't it be simpler to just take \co{countermax} counts?
>  \QuickQuizAnswer{
>  	First, it really is reserving \co{countermax} counts
> @@ -1902,7 +1902,7 @@ This task is undertaken in the next section.
>  \subsection{Approximate Limit Counter Implementation}
>  \label{sec:count:Approximate Limit Counter Implementation}
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 unsigned long __thread counter = 0;
> @@ -1918,10 +1918,10 @@ This task is undertaken in the next section.
>  \centering
>  \theverbbox
>  \caption{Approximate Limit Counter Variables}
> -\label{fig:count:Approximate Limit Counter Variables}
> -\end{figure}
> +\label{lst:count:Approximate Limit Counter Variables}
> +\end{listing}
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 static void balance_count(void)
> @@ -1942,25 +1942,25 @@ This task is undertaken in the next section.
>  \centering
>  \theverbbox
>  \caption{Approximate Limit Counter Balancing}
> -\label{fig:count:Approximate Limit Counter Balancing}
> -\end{figure}
> +\label{lst:count:Approximate Limit Counter Balancing}
> +\end{listing}
> 
>  Because this implementation (\path{count_lim_app.c}) is quite similar to
>  that in the previous section
> -(Figures~\ref{fig:count:Simple Limit Counter Variables},
> -\ref{fig:count:Simple Limit Counter Add, Subtract, and Read}, and
> -\ref{fig:count:Simple Limit Counter Utility Functions}),
> +(Listings~\ref{lst:count:Simple Limit Counter Variables},
> +\ref{lst:count:Simple Limit Counter Add, Subtract, and Read}, and
> +\ref{lst:count:Simple Limit Counter Utility Functions}),
>  only the changes are shown here.
> -Figure~\ref{fig:count:Approximate Limit Counter Variables}
> +Listing~\ref{lst:count:Approximate Limit Counter Variables}
>  is identical to
> -Figure~\ref{fig:count:Simple Limit Counter Variables},
> +Listing~\ref{lst:count:Simple Limit Counter Variables},
>  with the addition of \co{MAX_COUNTERMAX}, which sets the maximum
>  permissible value of the per-thread \co{countermax} variable.
> 
>  Similarly,
> -Figure~\ref{fig:count:Approximate Limit Counter Balancing}
> +Listing~\ref{lst:count:Approximate Limit Counter Balancing}
>  is identical to the \co{balance_count()} function in
> -Figure~\ref{fig:count:Simple Limit Counter Utility Functions},
> +Listing~\ref{lst:count:Simple Limit Counter Utility Functions},
>  with the addition of lines~6 and 7, which enforce the
>  \co{MAX_COUNTERMAX} limit on the per-thread \co{countermax} variable.
> 
> @@ -2038,7 +2038,7 @@ represent \co{counter} and the low-order 16 bits to represent
>  	the reader.
>  } \QuickQuizEnd
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 atomic_t __thread ctrandmax = ATOMIC_INIT(0);
> @@ -2079,12 +2079,12 @@ represent \co{counter} and the low-order 16 bits to represent
>  \centering
>  \theverbbox
>  \caption{Atomic Limit Counter Variables and Access Functions}
> -\label{fig:count:Atomic Limit Counter Variables and Access Functions}
> -\end{figure}
> +\label{lst:count:Atomic Limit Counter Variables and Access Functions}
> +\end{listing}
> 
>  The variables and access functions for a simple atomic limit counter
>  are shown in
> -Figure~\ref{fig:count:Atomic Limit Counter Variables and Access Functions}
> +Listing~\ref{lst:count:Atomic Limit Counter Variables and Access Functions}
>  (\path{count_lim_atomic.c}).
>  The \co{counter} and \co{countermax} variables in earlier algorithms
>  are combined into the single variable \co{ctrandmax} shown on
> @@ -2096,7 +2096,7 @@ representation of \co{int}.
>  Lines~2-6 show the definitions for \co{globalcountmax}, \co{globalcount},
>  \co{globalreserve}, \co{counterp}, and \co{gblcnt_mutex}, all of which
>  take on roles similar to their counterparts in
> -Figure~\ref{fig:count:Approximate Limit Counter Variables}.
> +Listing~\ref{lst:count:Approximate Limit Counter Variables}.
>  Line~7 defines \co{CM_BITS}, which gives the number of bits in each half
>  of \co{ctrandmax}, and line~8 defines \co{MAX_COUNTERMAX}, which
>  gives the maximum value that may be held in either half of
> @@ -2104,7 +2104,7 @@ gives the maximum value that may be held in either half of
> 
>  \QuickQuiz{}
>  	In what way does line~7 of
> -	Figure~\ref{fig:count:Atomic Limit Counter Variables and Access Functions}
> +	Listing~\ref{lst:count:Atomic Limit Counter Variables and Access Functions}
>  	violate the C standard?
>  \QuickQuizAnswer{
>  	It assumes eight bits per byte.
> @@ -2134,7 +2134,7 @@ it on line~24.
>  \QuickQuiz{}
>  	Given that there is only one \co{ctrandmax} variable,
>  	why bother passing in a pointer to it on line~18 of
> -	Figure~\ref{fig:count:Atomic Limit Counter Variables and Access Functions}?
> +	Listing~\ref{lst:count:Atomic Limit Counter Variables and Access Functions}?
>  \QuickQuizAnswer{
>  	There is only one \co{ctrandmax} variable \emph{per thread}.
>  	Later, we will see code that needs to pass other threads'
> @@ -2149,7 +2149,7 @@ the result.
> 
>  \QuickQuiz{}
>  	Why does \co{merge_ctrandmax()} in
> -	Figure~\ref{fig:count:Atomic Limit Counter Variables and Access Functions}
> +	Listing~\ref{lst:count:Atomic Limit Counter Variables and Access Functions}
>  	return an \co{int} rather than storing directly into an
>  	\co{atomic_t}?
>  \QuickQuizAnswer{
> @@ -2157,7 +2157,7 @@ the result.
>  	to the \co{atomic_cmpxchg()} primitive.
>  } \QuickQuizEnd
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 int add_count(unsigned long delta)
> @@ -2228,10 +2228,10 @@ the result.
>  \centering
>  \theverbbox
>  \caption{Atomic Limit Counter Add and Subtract}
> -\label{fig:count:Atomic Limit Counter Add and Subtract}
> -\end{figure}
> +\label{lst:count:Atomic Limit Counter Add and Subtract}
> +\end{listing}
> 
> -Figure~\ref{fig:count:Atomic Limit Counter Add and Subtract}
> +Listing~\ref{lst:count:Atomic Limit Counter Add and Subtract}
>  shows the \co{add_count()} and \co{sub_count()} functions.
> 
>  Lines~1-32 show \co{add_count()}, whose fastpath spans lines~8-15,
> @@ -2256,7 +2256,7 @@ execution continues in the loop at line~9.
>  \QuickQuiz{}
>  	Yecch!
>  	Why the ugly \co{goto} on line~11 of
> -	Figure~\ref{fig:count:Atomic Limit Counter Add and Subtract}?
> +	Listing~\ref{lst:count:Atomic Limit Counter Add and Subtract}?
>  	Haven't you heard of the \co{break} statement???
>  \QuickQuizAnswer{
>  	Replacing the \co{goto} with a \co{break} would require keeping
> @@ -2271,20 +2271,20 @@ execution continues in the loop at line~9.
> 
>  \QuickQuiz{}
>  	Why would the \co{atomic_cmpxchg()} primitive at lines~13-14 of
> -	Figure~\ref{fig:count:Atomic Limit Counter Add and Subtract}
> +	Listing~\ref{lst:count:Atomic Limit Counter Add and Subtract}
>  	ever fail?
>  	After all, we picked up its old value on line~9 and have not
>  	changed it!
>  \QuickQuizAnswer{
>  	Later, we will see how the \co{flush_local_count()} function in
> -	Figure~\ref{fig:count:Atomic Limit Counter Utility Functions 1}
> +	Listing~\ref{lst:count:Atomic Limit Counter Utility Functions 1}
>  	might update this thread's \co{ctrandmax} variable concurrently
>  	with the execution of the fastpath on lines~8-14 of
> -	Figure~\ref{fig:count:Atomic Limit Counter Add and Subtract}.
> +	Listing~\ref{lst:count:Atomic Limit Counter Add and Subtract}.
>  } \QuickQuizEnd
> 
>  Lines~16-31 of
> -Figure~\ref{fig:count:Atomic Limit Counter Add and Subtract}
> +Listing~\ref{lst:count:Atomic Limit Counter Add and Subtract}
>  show \co{add_count()}'s slowpath, which is protected by \co{gblcnt_mutex},
>  which is acquired on line~17 and released on lines~24 and 30.
>  Line~18 invokes \co{globalize_count()}, which moves this thread's
> @@ -2304,14 +2304,14 @@ spreads counts to the local state if appropriate, line~30 releases
>  returns success.
> 
>  Lines~34-63 of
> -Figure~\ref{fig:count:Atomic Limit Counter Add and Subtract}
> +Listing~\ref{lst:count:Atomic Limit Counter Add and Subtract}
>  show \co{sub_count()}, which is structured similarly to
>  \co{add_count()}, having a fastpath on lines~41-48 and a slowpath on
>  lines~49-62.
>  A line-by-line analysis of this function is left as an exercise to
>  the reader.
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 unsigned long read_count(void)
> @@ -2337,10 +2337,10 @@ the reader.
>  \centering
>  \theverbbox
>  \caption{Atomic Limit Counter Read}
> -\label{fig:count:Atomic Limit Counter Read}
> -\end{figure}
> +\label{lst:count:Atomic Limit Counter Read}
> +\end{listing}
> 
> -Figure~\ref{fig:count:Atomic Limit Counter Read} shows \co{read_count()}.
> +Listing~\ref{lst:count:Atomic Limit Counter Read} shows \co{read_count()}.
>  Line~9 acquires \co{gblcnt_mutex} and line~16 releases it.
>  Line~10 initializes local variable \co{sum} to the value of
>  \co{globalcount}, and the loop spanning lines~11-15 adds the
> @@ -2348,7 +2348,7 @@ per-thread counters to this sum, isolating each per-thread counter
>  using \co{split_ctrandmax} on line~13.
>  Finally, line~17 returns the sum.
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 static void globalize_count(void)
> @@ -2388,10 +2388,10 @@ Finally, line~17 returns the sum.
>  \centering
>  \theverbbox
>  \caption{Atomic Limit Counter Utility Functions 1}
> -\label{fig:count:Atomic Limit Counter Utility Functions 1}
> -\end{figure}
> +\label{lst:count:Atomic Limit Counter Utility Functions 1}
> +\end{listing}
> 
> -\begin{figure}[tb]
> +\begin{listing}[tb]
>  { \scriptsize
>  \begin{verbbox}
>    1 static void balance_count(void)
> @@ -2440,11 +2440,11 @@ Finally, line~17 returns the sum.
>  \centering
>  \theverbbox
>  \caption{Atomic Limit Counter Utility Functions 2}
> -\label{fig:count:Atomic Limit Counter Utility Functions 2}
> -\end{figure}
> +\label{lst:count:Atomic Limit Counter Utility Functions 2}
> +\end{listing}
> 
> -Figures~\ref{fig:count:Atomic Limit Counter Utility Functions 1}
> -and~\ref{fig:count:Atomic Limit Counter Utility Functions 2}
> +Listings~\ref{lst:count:Atomic Limit Counter Utility Functions 1}
> +and~\ref{lst:count:Atomic Limit Counter Utility Functions 2}
>  shows the utility functions
>  \co{globalize_count()},
>  \co{flush_local_count()},
> @@ -2452,7 +2452,7 @@ shows the utility functions
>  \co{count_register_thread()}, and
>  \co{count_unregister_thread()}.
>  The code for \co{globalize_count()} is shown on lines~1-12,
> -of Figure~\ref{fig:count:Atomic Limit Counter Utility Functions 1} and
> +of Listing~\ref{lst:count:Atomic Limit Counter Utility Functions 1} and
>  is similar to that of previous algorithms, with the addition of
>  line~7, which is now required to split out \co{counter} and
>  \co{countermax} from \co{ctrandmax}.
> @@ -2477,7 +2477,7 @@ line~30 subtracts this thread's \co{countermax} from \co{globalreserve}.
>  	What stops a thread from simply refilling its
>  	\co{ctrandmax} variable immediately after
>  	\co{flush_local_count()} on line~14 of
> -	Figure~\ref{fig:count:Atomic Limit Counter Utility Functions 1}
> +	Listing~\ref{lst:count:Atomic Limit Counter Utility Functions 1}
>  	empties it?
>  \QuickQuizAnswer{
>  	This other thread cannot refill its \co{ctrandmax}
> @@ -2494,7 +2494,7 @@ line~30 subtracts this thread's \co{countermax} from \co{globalreserve}.
>  	\co{add_count()} or \co{sub_count()} from interfering with
>  	the \co{ctrandmax} variable while
>  	\co{flush_local_count()} is accessing it on line~27 of
> -	Figure~\ref{fig:count:Atomic Limit Counter Utility Functions 1}
> +	Listing~\ref{lst:count:Atomic Limit Counter Utility Functions 1}
>  	empties it?
>  \QuickQuizAnswer{
>  	Nothing.
> @@ -2520,7 +2520,7 @@ line~30 subtracts this thread's \co{countermax} from \co{globalreserve}.
>  } \QuickQuizEnd
> 
>  Lines~1-22 on
> -Figure~\ref{fig:count:Atomic Limit Counter Utility Functions 2}
> +Listing~\ref{lst:count:Atomic Limit Counter Utility Functions 2}
>  show the code for \co{balance_count()}, which refills
>  the calling thread's local \co{ctrandmax} variable.
>  This function is quite similar to that of the preceding algorithms,
> @@ -2534,7 +2534,7 @@ line~33.
>  	Given that the \co{atomic_set()} primitive does a simple
>  	store to the specified \co{atomic_t}, how can line~21 of
>  	\co{balance_count()} in
> -	Figure~\ref{fig:count:Atomic Limit Counter Utility Functions 2}
> +	Listing~\ref{lst:count:Atomic Limit Counter Utility Functions 2}
>  	work correctly in face of concurrent \co{flush_local_count()}
>  	updates to this variable?
>  \QuickQuizAnswer{
> @@ -2668,7 +2668,7 @@ The slowpath then sets that thread's \co{theft} state to IDLE.
>  \subsection{Signal-Theft Limit Counter Implementation}
>  \label{sec:count:Signal-Theft Limit Counter Implementation}
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 #define THEFT_IDLE  0
> @@ -2693,10 +2693,10 @@ The slowpath then sets that thread's \co{theft} state to IDLE.
>  \centering
>  \theverbbox
>  \caption{Signal-Theft Limit Counter Data}
> -\label{fig:count:Signal-Theft Limit Counter Data}
> -\end{figure}
> +\label{lst:count:Signal-Theft Limit Counter Data}
> +\end{listing}
> 
> -Figure~\ref{fig:count:Signal-Theft Limit Counter Data}
> +Listing~\ref{lst:count:Signal-Theft Limit Counter Data}
>  (\path{count_lim_sig.c})
>  shows the data structures used by the signal-theft based counter
>  implementation.
> @@ -2706,7 +2706,7 @@ Lines~8-17 are similar to earlier implementations, with the addition of
>  lines~14 and 15 to allow remote access to a thread's \co{countermax}
>  and \co{theft} variables, respectively.
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 static void globalize_count(void)
> @@ -2777,10 +2777,10 @@ and \co{theft} variables, respectively.
>  \centering
>  \theverbbox
>  \caption{Signal-Theft Limit Counter Value-Migration Functions}
> -\label{fig:count:Signal-Theft Limit Counter Value-Migration Functions}
> -\end{figure}
> +\label{lst:count:Signal-Theft Limit Counter Value-Migration Functions}
> +\end{listing}
> 
> -Figure~\ref{fig:count:Signal-Theft Limit Counter Value-Migration Functions}
> +Listing~\ref{lst:count:Signal-Theft Limit Counter Value-Migration Functions}
>  shows the functions responsible for migrating counts between per-thread
>  variables and the global variables.
>  Lines~1-7 shows \co{globalize_count()}, which is identical to earlier
> @@ -2796,7 +2796,7 @@ this thread's fastpaths are not running, line~16 sets the \co{theft}
>  state to READY.
> 
>  \QuickQuiz{}
> -	In Figure~\ref{fig:count:Signal-Theft Limit Counter Value-Migration Functions}
> +	In Listing~\ref{lst:count:Signal-Theft Limit Counter Value-Migration Functions}
>  	function \co{flush_local_count_sig()}, why are there
>  	\co{ACCESS_ONCE()} wrappers around the uses of the
>  	\co{theft} per-thread variable?
> @@ -2835,7 +2835,7 @@ Otherwise, line~32 sets the thread's \co{theft} state to REQ and
>  line~33 sends the thread a signal.
> 
>  \QuickQuiz{}
> -	In Figure~\ref{fig:count:Signal-Theft Limit Counter Value-Migration Functions},
> +	In Listing~\ref{lst:count:Signal-Theft Limit Counter Value-Migration Functions},
>  	why is it safe for line~28 to directly access the other thread's
>  	\co{countermax} variable?
>  \QuickQuizAnswer{
> @@ -2849,7 +2849,7 @@ line~33 sends the thread a signal.
>  } \QuickQuizEnd
> 
>  \QuickQuiz{}
> -	In Figure~\ref{fig:count:Signal-Theft Limit Counter Value-Migration Functions},
> +	In Listing~\ref{lst:count:Signal-Theft Limit Counter Value-Migration Functions},
>  	why doesn't line~33 check for the current thread sending itself
>  	a signal?
>  \QuickQuizAnswer{
> @@ -2861,7 +2861,7 @@ line~33 sends the thread a signal.
> 
>  \QuickQuiz{}
>  	The code in
> -	Figure~\ref{fig:count:Signal-Theft Limit Counter Value-Migration Functions},
> +	Listing~\ref{lst:count:Signal-Theft Limit Counter Value-Migration Functions},
>  	works with \GCC\ and POSIX.
>  	What would be required to make it also conform to the ISO C standard?
>  \QuickQuizAnswer{
> @@ -2882,7 +2882,7 @@ READY, so lines~43-46 do the thieving.
>  Line~47 then sets the thread's \co{theft} state back to IDLE.
> 
>  \QuickQuiz{}
> -	In Figure~\ref{fig:count:Signal-Theft Limit Counter Value-Migration Functions}, why does line~41 resend the signal?
> +	In Listing~\ref{lst:count:Signal-Theft Limit Counter Value-Migration Functions}, why does line~41 resend the signal?
>  \QuickQuizAnswer{
>  	Because many operating systems over several decades have
>  	had the property of losing the occasional signal.
> @@ -2897,7 +2897,7 @@ Line~47 then sets the thread's \co{theft} state back to IDLE.
>  Lines~51-63 show \co{balance_count()}, which is similar to that of
>  earlier examples.
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 int add_count(unsigned long delta)
> @@ -2941,10 +2941,10 @@ earlier examples.
>  \centering
>  \theverbbox
>  \caption{Signal-Theft Limit Counter Add Function}
> -\label{fig:count:Signal-Theft Limit Counter Add Function}
> -\end{figure}
> +\label{lst:count:Signal-Theft Limit Counter Add Function}
> +\end{listing}
> 
> -\begin{figure}[tb]
> +\begin{listing}[tb]
>  { \scriptsize
>  \begin{verbbox}
>   38 int sub_count(unsigned long delta)
> @@ -2986,10 +2986,10 @@ earlier examples.
>  \centering
>  \theverbbox
>  \caption{Signal-Theft Limit Counter Subtract Function}
> -\label{fig:count:Signal-Theft Limit Counter Subtract Function}
> -\end{figure}
> +\label{lst:count:Signal-Theft Limit Counter Subtract Function}
> +\end{listing}
> 
> -Figure~\ref{fig:count:Signal-Theft Limit Counter Add Function}
> +Listing~\ref{lst:count:Signal-Theft Limit Counter Add Function}
>  shows the \co{add_count()} function.
>  The fastpath spans lines~5-20, and the slowpath lines~21-35.
>  Line~5 sets the per-thread \co{counting} variable to 1 so that
> @@ -3014,7 +3014,7 @@ READY also sees the effects of line~9.
>  If the fastpath addition at line~9 was executed, then line~20 returns
>  success.
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 unsigned long read_count(void)
> @@ -3035,21 +3035,21 @@ success.
>  \centering
>  \theverbbox
>  \caption{Signal-Theft Limit Counter Read Function}
> -\label{fig:count:Signal-Theft Limit Counter Read Function}
> -\end{figure}
> +\label{lst:count:Signal-Theft Limit Counter Read Function}
> +\end{listing}
> 
>  Otherwise, we fall through to the slowpath starting at line~21.
>  The structure of the slowpath is similar to those of earlier examples,
>  so its analysis is left as an exercise to the reader.
>  Similarly, the structure of \co{sub_count()} on
> -Figure~\ref{fig:count:Signal-Theft Limit Counter Subtract Function}
> +Listing~\ref{lst:count:Signal-Theft Limit Counter Subtract Function}
>  is the same
>  as that of \co{add_count()}, so the analysis of \co{sub_count()} is also
>  left as an exercise for the reader, as is the analysis of
>  \co{read_count()} in
> -Figure~\ref{fig:count:Signal-Theft Limit Counter Read Function}.
> +Listing~\ref{lst:count:Signal-Theft Limit Counter Read Function}.
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 void count_init(void)
> @@ -3092,11 +3092,11 @@ Figure~\ref{fig:count:Signal-Theft Limit Counter Read Function}.
>  \centering
>  \theverbbox
>  \caption{Signal-Theft Limit Counter Initialization Functions}
> -\label{fig:count:Signal-Theft Limit Counter Initialization Functions}
> -\end{figure}
> +\label{lst:count:Signal-Theft Limit Counter Initialization Functions}
> +\end{listing}
> 
>  Lines~1-12 of
> -Figure~\ref{fig:count:Signal-Theft Limit Counter Initialization Functions}
> +Listing~\ref{lst:count:Signal-Theft Limit Counter Initialization Functions}
>  show \co{count_init()}, which set up \co{flush_local_count_sig()}
>  as the signal handler for \co{SIGUSR1},
>  enabling the \co{pthread_kill()} calls in \co{flush_local_count()}
> @@ -3414,7 +3414,7 @@ courtesy of eventual consistency.
>  \label{tab:count:Limit Counter Performance on Power-6}
>  \end{table*}
> 
> -Figure~\ref{tab:count:Limit Counter Performance on Power-6}
> +Table~\ref{tab:count:Limit Counter Performance on Power-6}
>  shows the performance of the parallel limit-counting algorithms.
>  Exact enforcement of the limits incurs a substantial performance
>  penalty, although on this 4.7\,GHz \Power{6} system that penalty can be reduced
> diff --git a/defer/rcuexercises.tex b/defer/rcuexercises.tex
> index 1d9e138..21d9683 100644
> --- a/defer/rcuexercises.tex
> +++ b/defer/rcuexercises.tex
> @@ -14,7 +14,7 @@ suffice for most of these exercises.
> 
>  \QuickQuiz{}
>  	The statistical-counter implementation shown in
> -	Figure~\ref{fig:count:Per-Thread Statistical Counters}
> +	Listing~\ref{lst:count:Per-Thread Statistical Counters}
>  	(\path{count_end.c})
>  	used a global lock to guard the summation in \co{read_count()},
>  	which resulted in poor performance and negative scalability.
> diff --git a/howto/howto.tex b/howto/howto.tex
> index 90abb14..1a0b75c 100644
> --- a/howto/howto.tex
> +++ b/howto/howto.tex
> @@ -361,7 +361,7 @@ Other types of systems have well-known ways of locating files by filename.
>  \section{Whose Book Is This?}
>  \label{sec:howto:Whose Book Is This?}
> 
> -\begin{figure*}[tbp]
> +\begin{listing*}[tbp]
>  {
>  \scriptsize
>  \begin{verbbox}
> @@ -376,10 +376,10 @@ Other types of systems have well-known ways of locating files by filename.
>  }
>  \hspace*{1in}\OneColumnHSpace{-0.5in}\theverbbox
>  \caption{Creating an Up-To-Date PDF}
> -\label{fig:howto:Creating a Up-To-Date PDF}
> -\end{figure*}
> +\label{lst:howto:Creating a Up-To-Date PDF}
> +\end{listing*}
> 
> -\begin{figure*}[tbp]
> +\begin{listing*}[tbp]
>  {
>  \scriptsize
>  \begin{verbbox}
> @@ -393,8 +393,8 @@ Other types of systems have well-known ways of locating files by filename.
>  }
>  \hspace*{1in}\OneColumnHSpace{-0.5in}\theverbbox
>  \caption{Generating an Updated PDF}
> -\label{fig:howto:Generating an Updated PDF}
> -\end{figure*}
> +\label{lst:howto:Generating an Updated PDF}
> +\end{listing*}
> 
>  As the cover says, the editor is one Paul E.~McKenney.
>  However, the editor does accept contributions via the
> @@ -416,18 +416,18 @@ in the file \path{FAQ-BUILD.txt} in the \LaTeX{} source to the book.
> 
>  To create and display a current \LaTeX{} source tree of this book,
>  use the list of Linux commands shown in
> -Figure~\ref{fig:howto:Creating a Up-To-Date PDF}.
> +Listing~\ref{lst:howto:Creating a Up-To-Date PDF}.
>  In some environments, the \co{evince} command that displays \path{perfbook.pdf}
>  may need to be replaced, for example, with \co{acroread}.
>  The \co{git clone} command need only be used the first time you
>  create a PDF, subsequently, you can run the commands shown in
> -Figure~\ref{fig:howto:Generating an Updated PDF} to pull in any updates
> +Listing~\ref{lst:howto:Generating an Updated PDF} to pull in any updates
>  and generate an updated PDF.
>  The commands in
> -Figure~\ref{fig:howto:Generating an Updated PDF}
> +Listing~\ref{lst:howto:Generating an Updated PDF}
>  must be run within the \path{perfbook} directory created by the commands
>  shown in
> -Figure~\ref{fig:howto:Creating a Up-To-Date PDF}.
> +Listing~\ref{lst:howto:Creating a Up-To-Date PDF}.
> 
>  PDFs of this book are sporadically posted at
>  \url{http://kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html}
> diff --git a/owned/owned.tex b/owned/owned.tex
> index f74b5d6..d584e82 100644
> --- a/owned/owned.tex
> +++ b/owned/owned.tex
> @@ -132,8 +132,8 @@ is obviously quite attractive.
>  } \QuickQuizEnd
> 
>  This same pattern can be written in C as well as in \co{sh}, as illustrated by
> -Figures~\ref{fig:toolsoftrade:Using the fork() Primitive}
> -and~\ref{fig:toolsoftrade:Using the wait() Primitive}.
> +Listings~\ref{lst:toolsoftrade:Using the fork() Primitive}
> +and~\ref{lst:toolsoftrade:Using the wait() Primitive}.
> 
>  The next section discusses use of data ownership in shared-memory
>  parallel programs.
> @@ -150,8 +150,8 @@ of ownership and access rights.
> 
>  For example, consider the per-thread statistical counter implementation
>  shown in
> -Figure~\ref{fig:count:Per-Thread Statistical Counters} on
> -page~\pageref{fig:count:Per-Thread Statistical Counters}.
> +Listing~\ref{lst:count:Per-Thread Statistical Counters} on
> +page~\pageref{lst:count:Per-Thread Statistical Counters}.
>  Here, \co{inc_count()} updates only the corresponding thread's
>  instance of \co{counter},
>  while \co{read_count()} accesses, but does not modify, all
> @@ -195,9 +195,9 @@ beginning on
>  page~\pageref{sec:count:Signal-Theft Limit Counter Design},
>  in particular the \co{flush_local_count_sig()} and
>  \co{flush_local_count()} functions in
> -Figure~\ref{fig:count:Signal-Theft Limit Counter Value-Migration Functions}
> +Listing~\ref{lst:count:Signal-Theft Limit Counter Value-Migration Functions}
>  on
> -page~\pageref{fig:count:Signal-Theft Limit Counter Value-Migration Functions}.
> +page~\pageref{lst:count:Signal-Theft Limit Counter Value-Migration Functions}.
> 
>  The \co{flush_local_count_sig()} function is a signal handler that
>  acts as the shipped function.
> @@ -207,12 +207,12 @@ the shipped function executes.
>  This shipped function has the not-unusual added complication of
>  needing to interact with any concurrently executing \co{add_count()}
>  or \co{sub_count()} functions (see
> -Figure~\ref{fig:count:Signal-Theft Limit Counter Add Function}
> +Listing~\ref{lst:count:Signal-Theft Limit Counter Add Function}
>  on
> -page~\pageref{fig:count:Signal-Theft Limit Counter Add Function} and
> -Figure~\ref{fig:count:Signal-Theft Limit Counter Subtract Function}
> +page~\pageref{lst:count:Signal-Theft Limit Counter Add Function} and
> +Listing~\ref{lst:count:Signal-Theft Limit Counter Subtract Function}
>  on
> -page~\pageref{fig:count:Signal-Theft Limit Counter Subtract Function}).
> +page~\pageref{lst:count:Signal-Theft Limit Counter Subtract Function}).
> 
>  \QuickQuiz{}
>  	What mechanisms other than POSIX signals may be used for function
> @@ -246,7 +246,7 @@ The eventually consistent counter implementation described in
>  Section~\ref{sec:count:Eventually Consistent Implementation} provides an example.
>  This implementation has a designated thread that runs the
>  \co{eventual()} function shown on lines~15-32 of
> -Figure~\ref{fig:count:Array-Based Per-Thread Eventually Consistent Counters}.
> +Listing~\ref{lst:count:Array-Based Per-Thread Eventually Consistent Counters}.
>  This \co{eventual()} thread periodically pulls the per-thread counts
>  into the global counter, so that accesses to the global counter will,
>  as the name says, eventually converge on the actual value.
> @@ -254,7 +254,7 @@ as the name says, eventually converge on the actual value.
>  \QuickQuiz{}
>  	But none of the data in the \co{eventual()} function shown on
>  	lines~15-32 of
> -	Figure~\ref{fig:count:Array-Based Per-Thread Eventually Consistent Counters}
> +	Listing~\ref{lst:count:Array-Based Per-Thread Eventually Consistent Counters}
>  	is actually owned by the \co{eventual()} thread!
>  	In just what way is this data ownership???
>  \QuickQuizAnswer{
> @@ -298,8 +298,8 @@ a considerable reduction in the spread of certain types of disease.
> 
>  In other cases, privatization imposes costs.
>  For example, consider the simple limit counter shown in
> -Figure~\ref{fig:count:Simple Limit Counter Add, Subtract, and Read} on
> -page~\pageref{fig:count:Simple Limit Counter Add, Subtract, and Read}.
> +Listing~\ref{lst:count:Simple Limit Counter Add, Subtract, and Read} on
> +page~\pageref{lst:count:Simple Limit Counter Add, Subtract, and Read}.
>  This is an example of an algorithm where threads can read each others'
>  data, but are only permitted to update their own data.
>  A quick review of the algorithm shows that the only cross-thread
> diff --git a/together/applyrcu.tex b/together/applyrcu.tex
> index e3d6f0d..d477ab5 100644
> --- a/together/applyrcu.tex
> +++ b/together/applyrcu.tex
> @@ -21,8 +21,8 @@ Unfortunately, threads needing to read out the value via \co{read_count()}
>  were required to acquire a global
>  lock, and thus incurred high overhead and suffered poor scalability.
>  The code for the lock-based implementation is shown in
> -Figure~\ref{fig:count:Per-Thread Statistical Counters} on
> -Page~\pageref{fig:count:Per-Thread Statistical Counters}.
> +Listing~\ref{lst:count:Per-Thread Statistical Counters} on
> +Page~\pageref{lst:count:Per-Thread Statistical Counters}.
> 
>  \QuickQuiz{}
>  	Why on earth did we need that global lock in the first place?
> @@ -56,8 +56,8 @@ execution.
>  	Just what is the accuracy of \co{read_count()}, anyway?
>  \QuickQuizAnswer{
>  	Refer to
> -	Figure~\ref{fig:count:Per-Thread Statistical Counters} on
> -	Page~\pageref{fig:count:Per-Thread Statistical Counters}.
> +	Listing~\ref{lst:count:Per-Thread Statistical Counters} on
> +	Page~\pageref{lst:count:Per-Thread Statistical Counters}.
>  	Clearly, if there are no concurrent invocations of \co{inc_count()},
>  	\co{read_count()} will return an exact result.
>  	However, if there \emph{are} concurrent invocations of
> @@ -205,7 +205,7 @@ the current \co{countarray} structure, and
>  the \co{final_mutex} spinlock.
> 
>  Lines~10-13 show \co{inc_count()}, which is unchanged from
> -Figure~\ref{fig:count:Per-Thread Statistical Counters}.
> +Listing~\ref{lst:count:Per-Thread Statistical Counters}.
> 
>  Lines~15-29 show \co{read_count()}, which has changed significantly.
>  Lines~21 and~27 substitute \co{rcu_read_lock()} and
> @@ -280,13 +280,13 @@ Line~69 can then safely free the old \co{countarray} structure.
>  	Wow!
>  	Figure~\ref{fig:together:RCU and Per-Thread Statistical Counters}
>  	contains 69 lines of code, compared to only 42 in
> -	Figure~\ref{fig:count:Per-Thread Statistical Counters}.
> +	Listing~\ref{lst:count:Per-Thread Statistical Counters}.
>  	Is this extra complexity really worth it?
>  \QuickQuizAnswer{
>  	This of course needs to be decided on a case-by-case basis.
>  	If you need an implementation of \co{read_count()} that
>  	scales linearly, then the lock-based implementation shown in
> -	Figure~\ref{fig:count:Per-Thread Statistical Counters}
> +	Listing~\ref{lst:count:Per-Thread Statistical Counters}
>  	simply will not work for you.
>  	On the other hand, if calls to \co{count_read()} are sufficiently
>  	rare, then the lock-based version is simpler and might thus be
> @@ -300,7 +300,7 @@ Line~69 can then safely free the old \co{countarray} structure.
>  	and the use of RCU unnecessary.
>  	This would in turn enable an implementation that
>  	was even simpler than the one shown in
> -	Figure~\ref{fig:count:Per-Thread Statistical Counters}, but
> +	Listing~\ref{lst:count:Per-Thread Statistical Counters}, but
>  	with all the scalability and performance benefits of the
>  	implementation shown in
>  	Figure~\ref{fig:together:RCU and Per-Thread Statistical Counters}!
> diff --git a/toolsoftrade/toolsoftrade.tex b/toolsoftrade/toolsoftrade.tex
> index bd43879..b18d3d0 100644
> --- a/toolsoftrade/toolsoftrade.tex
> +++ b/toolsoftrade/toolsoftrade.tex
> @@ -189,7 +189,7 @@ These concerns can of course add substantial complexity to the code.
>  For more information, see any of a number of textbooks on the
>  subject~\cite{WRichardStevens1992,StewartWeiss2013UNIX}.
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 pid = fork();
> @@ -207,14 +207,14 @@ subject~\cite{WRichardStevens1992,StewartWeiss2013UNIX}.
>  \centering
>  \theverbbox
>  \caption{Using the \tco{fork()} Primitive}
> -\label{fig:toolsoftrade:Using the fork() Primitive}
> -\end{figure}
> +\label{lst:toolsoftrade:Using the fork() Primitive}
> +\end{listing}
> 
>  If \co{fork()} succeeds, it returns twice, once for the parent
>  and again for the child.
>  The value returned from \co{fork()} allows the caller to tell
>  the difference, as shown in
> -Figure~\ref{fig:toolsoftrade:Using the fork() Primitive}
> +Listing~\ref{lst:toolsoftrade:Using the fork() Primitive}
>  (\path{forkjoin.c}).
>  Line~1 executes the \co{fork()} primitive, and saves its return value
>  in local variable \co{pid}.
> @@ -228,7 +228,7 @@ Otherwise, the \co{fork()} has executed successfully, and the parent
>  therefore executes line~9 with the variable \co{pid} containing the
>  process ID of the child.
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 void waitall(void)
> @@ -251,8 +251,8 @@ process ID of the child.
>  \centering
>  \theverbbox
>  \caption{Using the \tco{wait()} Primitive}
> -\label{fig:toolsoftrade:Using the wait() Primitive}
> -\end{figure}
> +\label{lst:toolsoftrade:Using the wait() Primitive}
> +\end{listing}
> 
>  The parent process may use the \co{wait()} primitive to wait for its children
>  to complete.
> @@ -261,7 +261,7 @@ counterpart, as each invocation of \co{wait()} waits for but one child
>  process.
>  It is therefore customary to wrap \co{wait()} into a function similar
>  to the \co{waitall()} function shown in
> -Figure~\ref{fig:toolsoftrade:Using the wait() Primitive}
> +Listing~\ref{lst:toolsoftrade:Using the wait() Primitive}
>  (\path{api-pthread.h}),
>  with this \co{waitall()} function having semantics similar to the
>  shell-script \co{wait} command.
> @@ -283,14 +283,14 @@ Otherwise, lines~11 and 12 print an error and exit.
>  	child individually.
>  	In addition, some parallel applications need to detect the
>  	reason that the child died.
> -	As we saw in Figure~\ref{fig:toolsoftrade:Using the wait() Primitive},
> +	As we saw in Listing~\ref{lst:toolsoftrade:Using the wait() Primitive},
>  	it is not hard to build a \co{waitall()} function out of
>  	the \co{wait()} function, but it would be impossible to
>  	do the reverse.
>  	Once the information about a specific child is lost, it is lost.
>  } \QuickQuizEnd
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 int x = 0;
> @@ -313,13 +313,13 @@ Otherwise, lines~11 and 12 print an error and exit.
>  \centering
>  \theverbbox
>  \caption{Processes Created Via \tco{fork()} Do Not Share Memory}
> -\label{fig:toolsoftrade:Processes Created Via fork() Do Not Share Memory}
> -\end{figure}
> +\label{lst:toolsoftrade:Processes Created Via fork() Do Not Share Memory}
> +\end{listing}
> 
>  It is critically important to note that the parent and child do \emph{not}
>  share memory.
>  This is illustrated by the program shown in
> -Figure~\ref{fig:toolsoftrade:Processes Created Via fork() Do Not Share Memory}
> +Listing~\ref{lst:toolsoftrade:Processes Created Via fork() Do Not Share Memory}
>  (\path{forkjoinvar.c}),
>  in which the child sets a global variable \co{x} to 1 on line~6,
>  prints a message on line~7, and exits on line~8.
> @@ -353,7 +353,7 @@ Parent process sees x=0
>  	source code of the Linux-kernel implementations themselves.
> 
>  	It is important to note that the parent process in
> -	Figure~\ref{fig:toolsoftrade:Processes Created Via fork() Do Not Share Memory}
> +	Listing~\ref{lst:toolsoftrade:Processes Created Via fork() Do Not Share Memory}
>  	waits until after the child terminates to do its \co{printf()}.
>  	Using \co{printf()}'s buffered I/O concurrently to the same file
>  	from multiple processes is non-trivial, and is best avoided.
> @@ -376,7 +376,7 @@ than fork-join parallelism.
>  To create a thread within an existing process, invoke the
>  \co{pthread_create()} primitive, for example, as shown on lines~15
>  and~16 of
> -Figure~\ref{fig:toolsoftrade:Threads Created Via pthread-create() Share Memory}
> +Listing~\ref{lst:toolsoftrade:Threads Created Via pthread-create() Share Memory}
>  (\path{pcreate.c}).
>  The first argument is a pointer to a \co{pthread_t} in which to store the
>  ID of the thread to be created, the second \co{NULL} argument is a pointer
> @@ -385,7 +385,7 @@ to an optional \co{pthread_attr_t}, the third argument is the function
>  that is to be invoked by the new thread, and the last \co{NULL} argument
>  is the argument that will be passed to \co{mythread}.
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 int x = 0;
> @@ -419,15 +419,15 @@ is the argument that will be passed to \co{mythread}.
>  \centering
>  \theverbbox
>  \caption{Threads Created Via \tco{pthread_create()} Share Memory}
> -\label{fig:toolsoftrade:Threads Created Via pthread-create() Share Memory}
> -\end{figure}
> +\label{lst:toolsoftrade:Threads Created Via pthread-create() Share Memory}
> +\end{listing}
> 
>  In this example, \co{mythread()} simply returns, but it could instead
>  call \co{pthread_exit()}.
> 
>  \QuickQuiz{}
>  	If the \co{mythread()} function in
> -	Figure~\ref{fig:toolsoftrade:Threads Created Via pthread-create() Share Memory}
> +	Listing~\ref{lst:toolsoftrade:Threads Created Via pthread-create() Share Memory}
>  	can simply return, why bother with \co{pthread_exit()}?
>  \QuickQuizAnswer{
>  	In this simple example, there is no reason whatsoever.
> @@ -450,7 +450,7 @@ or the value returned by the thread's top-level function, depending on
>  how the thread in question exits.
> 
>  The program shown in
> -Figure~\ref{fig:toolsoftrade:Threads Created Via pthread-create() Share Memory}
> +Listing~\ref{lst:toolsoftrade:Threads Created Via pthread-create() Share Memory}
>  produces output as follows, demonstrating that memory is in fact
>  shared between the two threads:
> 
> @@ -541,7 +541,7 @@ lock~\cite{Hoare74}.
>  	to the reader.
>  } \QuickQuizEnd
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 pthread_mutex_t lock_a = PTHREAD_MUTEX_INITIALIZER;
> @@ -598,11 +598,11 @@ lock~\cite{Hoare74}.
>  \centering
>  \theverbbox
>  \caption{Demonstration of Exclusive Locks}
> -\label{fig:toolsoftrade:Demonstration of Exclusive Locks}
> -\end{figure}
> +\label{lst:toolsoftrade:Demonstration of Exclusive Locks}
> +\end{listing}
> 
>  This exclusive-locking property is demonstrated using the code shown in
> -Figure~\ref{fig:toolsoftrade:Demonstration of Exclusive Locks}
> +Listing~\ref{lst:toolsoftrade:Demonstration of Exclusive Locks}
>  (\path{lock.c}).
>  Line~1 defines and initializes a POSIX lock named \co{lock_a}, while
>  line~2 similarly defines and initializes a lock named \co{lock_b}.
> @@ -618,7 +618,7 @@ primitives.
>  \QuickQuiz{}
>  	Why not simply make the argument to \co{lock_reader()}
>  	on line~5 of
> -	Figure~\ref{fig:toolsoftrade:Demonstration of Exclusive Locks}
> +	Listing~\ref{lst:toolsoftrade:Demonstration of Exclusive Locks}
>  	be a pointer to a \co{pthread_mutex_t}?
>  \QuickQuizAnswer{
>  	Because we will need to pass \co{lock_reader()} to
> @@ -653,7 +653,7 @@ required by \co{pthread_create()}.
>  } \QuickQuizEnd
> 
>  Lines~31-49 of
> -Figure~\ref{fig:toolsoftrade:Demonstration of Exclusive Locks}
> +Listing~\ref{lst:toolsoftrade:Demonstration of Exclusive Locks}
>  shows \co{lock_writer()}, which
>  periodically update the shared variable \co{x} while holding the
>  specified \co{pthread_mutex_t}.
> @@ -664,7 +664,7 @@ While holding the lock, lines~40-43 increment the shared variable \co{x},
>  sleeping for five milliseconds between each increment.
>  Finally, lines~44-47 release the lock.
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1   printf("Creating two threads using same lock:\n");
> @@ -691,10 +691,10 @@ Finally, lines~44-47 release the lock.
>  \centering
>  \theverbbox
>  \caption{Demonstration of Same Exclusive Lock}
> -\label{fig:toolsoftrade:Demonstration of Same Exclusive Lock}
> -\end{figure}
> +\label{lst:toolsoftrade:Demonstration of Same Exclusive Lock}
> +\end{listing}
> 
> -Figure~\ref{fig:toolsoftrade:Demonstration of Same Exclusive Lock}
> +Listing~\ref{lst:toolsoftrade:Demonstration of Same Exclusive Lock}
>  shows a code fragment that runs \co{lock_reader()} and
>  \co{lock_writer()} as threads using the same lock, namely, \co{lock_a}.
>  Lines~2-6 create a thread running \co{lock_reader()}, and then
> @@ -719,7 +719,7 @@ by \co{lock_writer()} while holding the lock.
>  \QuickQuiz{}
>  	Is ``x = 0'' the only possible output from the code fragment
>  	shown in
> -	Figure~\ref{fig:toolsoftrade:Demonstration of Same Exclusive Lock}?
> +	Listing~\ref{lst:toolsoftrade:Demonstration of Same Exclusive Lock}?
>  	If so, why?
>  	If not, what other output could appear, and why?
>  \QuickQuizAnswer{
> @@ -735,7 +735,7 @@ by \co{lock_writer()} while holding the lock.
>  	However, there are no guarantees, especially on a busy system.
>  } \QuickQuizEnd
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1   printf("Creating two threads w/different locks:\n");
> @@ -763,10 +763,10 @@ by \co{lock_writer()} while holding the lock.
>  \centering
>  \theverbbox
>  \caption{Demonstration of Different Exclusive Locks}
> -\label{fig:toolsoftrade:Demonstration of Different Exclusive Locks}
> -\end{figure}
> +\label{lst:toolsoftrade:Demonstration of Different Exclusive Locks}
> +\end{listing}
> 
> -Figure~\ref{fig:toolsoftrade:Demonstration of Different Exclusive Locks}
> +Listing~\ref{lst:toolsoftrade:Demonstration of Different Exclusive Locks}
>  shows a similar code fragment, but this time using different locks:
>  \co{lock_a} for \co{lock_reader()} and \co{lock_b} for
>  \co{lock_writer()}.
> @@ -811,7 +811,7 @@ values of \co{x} stored by \co{lock_writer()}.
> 
>  \QuickQuiz{}
>  	In the code shown in
> -	Figure~\ref{fig:toolsoftrade:Demonstration of Different Exclusive Locks},
> +	Listing~\ref{lst:toolsoftrade:Demonstration of Different Exclusive Locks},
>  	is \co{lock_reader()} guaranteed to see all the values produced
>  	by \co{lock_writer()}?
>  	Why or why not?
> @@ -825,19 +825,19 @@ values of \co{x} stored by \co{lock_writer()}.
> 
>  \QuickQuiz{}
>  	Wait a minute here!!!
> -	Figure~\ref{fig:toolsoftrade:Demonstration of Same Exclusive Lock}
> +	Listing~\ref{lst:toolsoftrade:Demonstration of Same Exclusive Lock}
>  	didn't initialize shared variable \co{x},
>  	so why does it need to be initialized in
> -	Figure~\ref{fig:toolsoftrade:Demonstration of Different Exclusive Locks}?
> +	Listing~\ref{lst:toolsoftrade:Demonstration of Different Exclusive Locks}?
>  \QuickQuizAnswer{
>  	See line~3 of
> -	Figure~\ref{fig:toolsoftrade:Demonstration of Exclusive Locks}.
> +	Listing~\ref{lst:toolsoftrade:Demonstration of Exclusive Locks}.
>  	Because the code in
> -	Figure~\ref{fig:toolsoftrade:Demonstration of Same Exclusive Lock}
> +	Listing~\ref{lst:toolsoftrade:Demonstration of Same Exclusive Lock}
>  	ran first, it could rely on the compile-time initialization of
>  	\co{x}.
>  	The code in
> -	Figure~\ref{fig:toolsoftrade:Demonstration of Different Exclusive Locks}
> +	Listing~\ref{lst:toolsoftrade:Demonstration of Different Exclusive Locks}
>  	ran next, so it had to re-initialize \co{x}.
>  } \QuickQuizEnd
> 
> @@ -873,7 +873,7 @@ an arbitrarily large number of readers to concurrently hold the lock.
>  However, in practice, we need to know how much additional scalability is
>  provided by reader-writer locks.
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 pthread_rwlock_t rwl = PTHREAD_RWLOCK_INITIALIZER;
> @@ -922,10 +922,10 @@ provided by reader-writer locks.
>  \centering
>  \theverbbox
>  \caption{Measuring Reader-Writer Lock Scalability}
> -\label{fig:toolsoftrade:Measuring Reader-Writer Lock Scalability}
> -\end{figure}
> +\label{lst:toolsoftrade:Measuring Reader-Writer Lock Scalability}
> +\end{listing}
> 
> -Figure~\ref{fig:toolsoftrade:Measuring Reader-Writer Lock Scalability}
> +Listing~\ref{lst:toolsoftrade:Measuring Reader-Writer Lock Scalability}
>  (\path{rwlockscale.c})
>  shows one way of measuring reader-writer lock scalability.
>  Line~1 shows the definition and initialization of the reader-writer
> @@ -955,7 +955,7 @@ rights to assume that the value of \co{goflag} would never change.
>  \QuickQuiz{}
>  	Instead of using \co{READ_ONCE()} everywhere, why not just
>  	declare \co{goflag} as \co{volatile} on line~10 of
> -	Figure~\ref{fig:toolsoftrade:Measuring Reader-Writer Lock Scalability}?
> +	Listing~\ref{lst:toolsoftrade:Measuring Reader-Writer Lock Scalability}?
>  \QuickQuizAnswer{
>  	A \co{volatile} declaration is in fact a reasonable alternative in
>  	this particular case.
> @@ -977,7 +977,7 @@ rights to assume that the value of \co{goflag} would never change.
>  	Don't we also need memory barriers to make sure
>  	that the change in \co{goflag}'s value propagates to the
>  	CPU in a timely fashion in
> -	Figure~\ref{fig:toolsoftrade:Measuring Reader-Writer Lock Scalability}?
> +	Listing~\ref{lst:toolsoftrade:Measuring Reader-Writer Lock Scalability}?
>  \QuickQuizAnswer{
>  	No, memory barriers are not needed and won't help here.
>  	Memory barriers only enforce ordering among multiple memory
> @@ -1167,7 +1167,7 @@ to protect the tiniest of critical sections.
>  One such way are atomic operations.
>  We have seen one atomic operations already, in the form of the
>  \co{__sync_fetch_and_add()} primitive on line~18 of
> -Figure~\ref{fig:toolsoftrade:Measuring Reader-Writer Lock Scalability}.
> +Listing~\ref{lst:toolsoftrade:Measuring Reader-Writer Lock Scalability}.
>  This primitive atomically adds the value of its second argument to
>  the value referenced by its first argument, returning the old value
>  (which was ignored in this case).
> @@ -1243,11 +1243,11 @@ In some cases, it is sufficient to constrain the compiler's ability
>  to reorder operations, while allowing the CPU free rein, in which
>  case the \co{barrier()} primitive may be used, as it in fact was
>  on line~28 of
> -Figure~\ref{fig:toolsoftrade:Measuring Reader-Writer Lock Scalability}.
> +Listing~\ref{lst:toolsoftrade:Measuring Reader-Writer Lock Scalability}.
>  In some cases, it is only necessary to ensure that the compiler
>  avoids optimizing away a given memory read, in which case the
>  \co{READ_ONCE()} primitive may be used, as it was on line~17 of
> -Figure~\ref{fig:toolsoftrade:Demonstration of Exclusive Locks}.
> +Listing~\ref{lst:toolsoftrade:Demonstration of Exclusive Locks}.
>  Similarly, the \co{WRITE_ONCE()} primitive may be used to prevent the
>  compiler from optimizing away a given memory write.
>  These last three primitives are not provided directly by \GCC,
> @@ -1416,10 +1416,10 @@ Threads share everything except for per-thread local state,\footnote{
>  which includes program counter and stack.
> 
>  The thread API is shown in
> -Figure~\ref{fig:toolsoftrade:Thread API}, and members are described in the
> +Listing~\ref{lst:toolsoftrade:Thread API}, and members are described in the
>  following sections.
> 
> -\begin{figure*}[tbp]
> +\begin{listing*}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>  int smp_thread_id(void)
> @@ -1433,8 +1433,8 @@ void wait_all_threads(void)
>  \centering
>  \theverbbox
>  \caption{Thread API}
> -\label{fig:toolsoftrade:Thread API}
> -\end{figure*}
> +\label{lst:toolsoftrade:Thread API}
> +\end{listing*}
> 
>  \subsubsection{\tco{create_thread()}}
> 
> @@ -1499,7 +1499,7 @@ a run, so such synchronization is normally not needed.
> 
>  \subsubsection{Example Usage}
> 
> -Figure~\ref{fig:toolsoftrade:Example Child Thread}
> +Listing~\ref{lst:toolsoftrade:Example Child Thread}
>  shows an example hello-world-like child thread.
>  As noted earlier, each thread is allocated its own stack, so
>  each thread has its own private \co{arg} argument and \co{myarg} variable.
> @@ -1509,7 +1509,7 @@ Note that the \co{return} statement on line~7 terminates the thread,
>  returning a \co{NULL} to whoever invokes \co{wait_thread()} on this
>  thread.
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 void *thread_test(void *arg)
> @@ -1525,11 +1525,11 @@ thread.
>  \centering
>  \theverbbox
>  \caption{Example Child Thread}
> -\label{fig:toolsoftrade:Example Child Thread}
> -\end{figure}
> +\label{lst:toolsoftrade:Example Child Thread}
> +\end{listing}
> 
>  The parent program is shown in
> -Figure~\ref{fig:toolsoftrade:Example Parent Thread}.
> +Listing~\ref{lst:toolsoftrade:Example Parent Thread}.
>  It invokes \co{smp_init()} to initialize the threading system on
>  line~6,
>  parses arguments on lines~7-14, and announces its presence on line~15.
> @@ -1538,7 +1538,7 @@ and waits for them to complete on line~18.
>  Note that \co{wait_all_threads()} discards the threads return values,
>  as in this case they are all \co{NULL}, which is not very interesting.
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>    1 int main(int argc, char *argv[])
> @@ -1567,8 +1567,8 @@ as in this case they are all \co{NULL}, which is not very interesting.
>  \centering
>  \theverbbox
>  \caption{Example Parent Thread}
> -\label{fig:toolsoftrade:Example Parent Thread}
> -\end{figure}
> +\label{lst:toolsoftrade:Example Parent Thread}
> +\end{listing}
> 
>  \QuickQuiz{}
>  	What happened to the Linux-kernel equivalents to \co{fork()}
> @@ -1584,11 +1584,11 @@ as in this case they are all \co{NULL}, which is not very interesting.
>  \label{sec:toolsoftrade:Locking}
> 
>  A good starting subset of the Linux kernel's locking API is shown in
> -Figure~\ref{fig:toolsoftrade:Locking API},
> +Listing~\ref{lst:toolsoftrade:Locking API},
>  each API element being described in the following sections.
>  This book's CodeSamples locking API closely follows that of the Linux kernel.
> 
> -\begin{figure}[tbp]
> +\begin{listing}[tbp]
>  { \scriptsize
>  \begin{verbbox}
>  void spin_lock_init(spinlock_t *sp);
> @@ -1600,8 +1600,8 @@ void spin_unlock(spinlock_t *sp);
>  \centering
>  \theverbbox
>  \caption{Locking API}
> -\label{fig:toolsoftrade:Locking API}
> -\end{figure}
> +\label{lst:toolsoftrade:Locking API}
> +\end{listing}
> 
>  \subsubsection{\tco{spin_lock_init()}}
> 
> @@ -1721,7 +1721,7 @@ given per-CPU variable, \co{per_cpu()} to access a specified CPU's
>  instance of a given per-CPU variable, along with many other special-purpose
>  per-CPU operations.
> 
> -Figure~\ref{fig:toolsoftrade:Per-Thread-Variable API}
> +Listing~\ref{lst:toolsoftrade:Per-Thread-Variable API}
>  shows this book's per-thread-variable API, which is patterned
>  after the Linux kernel's per-CPU-variable API.
>  This API provides the per-thread equivalent of global variables.
> @@ -1729,7 +1729,7 @@ Although this API is, strictly speaking, not necessary\footnote{
>  	You could instead use \co{__thread} or \co{_Thread_local}.},
>  it can provide a good userspace analogy to Linux kernel code.
> 
> -\begin{figure}[htbp]
> +\begin{listing}[htbp]
>  { \scriptsize
>  \begin{verbbox}
>  DEFINE_PER_THREAD(type, name)
> @@ -1742,8 +1742,8 @@ init_per_thread(name, v)
>  \centering
>  \theverbbox
>  \caption{Per-Thread-Variable API}
> -\label{fig:toolsoftrade:Per-Thread-Variable API}
> -\end{figure}
> +\label{lst:toolsoftrade:Per-Thread-Variable API}
> +\end{listing}
> 
>  \QuickQuiz{}
>  	How could you work around the lack of a per-thread-variable
> -- 
> 2.7.4
>