Signed-off-by: Akira Yokosawa <akiyks@xxxxxxxxx>
---
owned/owned.tex | 60 ++++++++++++++++++++++++-------------------------
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/owned/owned.tex b/owned/owned.tex
index df2a1cce..0d1d17f1 100644
--- a/owned/owned.tex
+++ b/owned/owned.tex
@@ -37,20 +37,20 @@ new examples, but will instead refer back to those of previous chapters.
}\QuickQuizEnd
There are a number of approaches to data ownership.
-Section~\ref{sec:owned:Multiple Processes} presents the logical extreme
+\Cref{sec:owned:Multiple Processes} presents the logical extreme
in data ownership, where each thread has its own private address space.
-Section~\ref{sec:owned:Partial Data Ownership and pthreads} looks at
+\Cref{sec:owned:Partial Data Ownership and pthreads} looks at
the opposite extreme, where the data is shared, but different threads
own different access rights to the data.
-Section~\ref{sec:owned:Function Shipping} describes function shipping,
+\Cref{sec:owned:Function Shipping} describes function shipping,
which is a way of allowing other threads to have indirect access to
data owned by a particular thread.
-Section~\ref{sec:owned:Designated Thread} describes how designated
+\Cref{sec:owned:Designated Thread} describes how designated
threads can be assigned ownership of a specified function and the
related data.
-Section~\ref{sec:owned:Privatization} discusses improving performance
+\Cref{sec:owned:Privatization} discusses improving performance
by transforming algorithms with shared data to instead use data ownership.
-Finally, Section~\ref{sec:owned:Other Uses of Data Ownership} lists
+Finally, \cref{sec:owned:Other Uses of Data Ownership} lists
a few software environments that feature data ownership as a
first-class citizen.
@@ -59,7 +59,7 @@ first-class citizen.
%
\epigraph{A man's home is his castle}{\emph{Ancient Laws of England}}
-Section~\ref{sec:toolsoftrade:Scripting Languages}
+\Cref{sec:toolsoftrade:Scripting Languages}
introduced the following example:
\begin{VerbatimN}[samepage=true]
@@ -81,7 +81,7 @@ is obviously quite attractive.
\QuickQuizSeries{%
\QuickQuizB{
What synchronization remains in the example shown in
- Section~\ref{sec:owned:Multiple Processes}?
+ \cref{sec:owned:Multiple Processes}?
}\QuickQuizAnswerB{
The creation of the threads via the \co{sh} \co{&} operator
and the joining of thread via the \co{sh} \co{wait}
@@ -113,7 +113,7 @@ is obviously quite attractive.
%
\QuickQuizE{
Is there any shared data in the example shown in
- Section~\ref{sec:owned:Multiple Processes}?
+ \cref{sec:owned:Multiple Processes}?
}\QuickQuizAnswerE{
That is a philosophical question.
@@ -134,8 +134,8 @@ is obviously quite attractive.
}
This same pattern can be written in C as well as in \co{sh}, as illustrated by
-Listings~\ref{lst:toolsoftrade:Using the fork() Primitive}
-and~\ref{lst:toolsoftrade:Using the wait() Primitive}.
+\cref{lst:toolsoftrade:Using the fork() Primitive,%
+lst:toolsoftrade:Using the wait() Primitive}.
It bears repeating that these trivial forms of parallelism are not in
any way cheating or ducking responsibility, but are rather simple and
@@ -167,8 +167,8 @@ of ownership and access rights.
For example, consider the per-thread statistical counter implementation
shown in
-Listing~\ref{lst:count:Per-Thread Statistical Counters} on
-page~\pageref{lst:count:Per-Thread Statistical Counters}.
+\cref{lst:count:Per-Thread Statistical Counters} on
+\cpageref{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
@@ -203,9 +203,9 @@ There are a great many variations on this theme.
For its own part, pure data ownership is also both common and useful,
for example, the per-thread memory-allocator caches discussed in
-Section~\ref{sec:SMPdesign:Resource Allocator Caches}
+\cref{sec:SMPdesign:Resource Allocator Caches}
starting on
-page~\pageref{sec:SMPdesign:Resource Allocator Caches}.
+\cpageref{sec:SMPdesign:Resource Allocator Caches}.
In this algorithm, each thread's cache is completely private to that
thread.
@@ -223,14 +223,14 @@ need it.
An alternative approach is to send the functions to the data.
Such an approach is illustrated in
-Section~\ref{sec:count:Signal-Theft Limit Counter Design}
+\cref{sec:count:Signal-Theft Limit Counter Design}
beginning on
-page~\pageref{sec:count:Signal-Theft Limit Counter Design},
+\cpageref{sec:count:Signal-Theft Limit Counter Design},
in particular the \co{flush_local_count_sig()} and
\co{flush_local_count()} functions in
-Listing~\ref{lst:count:Signal-Theft Limit Counter Value-Migration Functions}
+\cref{lst:count:Signal-Theft Limit Counter Value-Migration Functions}
on
-page~\pageref{lst:count:Signal-Theft Limit Counter Value-Migration Functions}.
+\cpageref{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.
@@ -240,12 +240,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
-Listing~\ref{lst:count:Signal-Theft Limit Counter Add Function}
+\cref{lst:count:Signal-Theft Limit Counter Add Function}
on
-page~\pageref{lst:count:Signal-Theft Limit Counter Add Function} and
-Listing~\ref{lst:count:Signal-Theft Limit Counter Subtract Function}
+\cpageref{lst:count:Signal-Theft Limit Counter Add Function} and
+\cref{lst:count:Signal-Theft Limit Counter Subtract Function}
on
-page~\pageref{lst:count:Signal-Theft Limit Counter Subtract Function}).
+\cpageref{lst:count:Signal-Theft Limit Counter Subtract Function}).
\QuickQuiz{
What mechanisms other than POSIX signals may be used for function
@@ -255,7 +255,7 @@ page~\pageref{lst:count:Signal-Theft Limit Counter Subtract Function}).
\begin{enumerate}
\item System V message queues.
\item Shared-memory dequeue (see
- Section~\ref{sec:SMPdesign:Double-Ended Queue}).
+ \cref{sec:SMPdesign:Double-Ended Queue}).
\item Shared-memory mailboxes.
\item UNIX-domain sockets.
\item TCP/IP or UDP, possibly augmented by any number of
@@ -280,10 +280,10 @@ where a special designated thread owns the rights to the data
that is required to do its job.
\begin{fcvref}[ln:count:count_stat_eventual:whole:eventual]
The eventually consistent counter implementation described in
-Section~\ref{sec:count:Eventually Consistent Implementation} provides an example.
+\cref{sec:count:Eventually Consistent Implementation} provides an example.
This implementation has a designated thread that runs the
\co{eventual()} function shown on \clnrefrange{b}{e} of
-Listing~\ref{lst:count:Array-Based Per-Thread Eventually Consistent Counters}.
+\cref{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.
@@ -293,7 +293,7 @@ as the name says, eventually converge on the actual value.
\begin{fcvref}[ln:count:count_stat_eventual:whole:eventual]
But none of the data in the \co{eventual()} function shown on
\clnrefrange{b}{e} of
- Listing~\ref{lst:count:Array-Based Per-Thread Eventually Consistent Counters}
+ \cref{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???
\end{fcvref}
@@ -304,7 +304,7 @@ as the name says, eventually converge on the actual value.
the per-thread \co{counter} variable defined on \clnref{per_thr_cnt}
of the listing.
This situation is similar to that described in
- Section~\ref{sec:owned:Partial Data Ownership and pthreads}.
+ \cref{sec:owned:Partial Data Ownership and pthreads}.
However, there really is data that is owned by the \co{eventual()}
thread, namely the \co{t} and \co{sum} variables defined on
@@ -329,7 +329,7 @@ private data that is owned by a particular thread.
An excellent example of this is shown in the answer to one of the
Quick Quizzes in
-Section~\ref{sec:SMPdesign:Dining Philosophers Problem},
+\cref{sec:SMPdesign:Dining Philosophers Problem},
which uses privatization to produce a solution to the
Dining Philosophers problem with much better performance and scalability
than that of the standard textbook solution.
@@ -424,7 +424,7 @@ Examples of data ownership include:
system~\cite{Belay:2016:IOS:3014162.2997641}.
IX does have some shared data structures, which use synchronization
mechanisms to be described in
- Section~\ref{sec:defer:Read-Copy Update (RCU)}.
+ \cref{sec:defer:Read-Copy Update (RCU)}.
\end{enumerate}
Data ownership is perhaps the most underappreciated synchronization
--
2.17.1
