concurrentparallel: More on logical concurrency and physical parallelism

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>

1 files changed, 28 insertions, 10 deletions

diff --git a/appendix/questions/concurrentparallel.tex b/appendix/questions/concurrentparallel.tex
index 4142420e..04bbf8a2 100644
--- a/appendix/questions/concurrentparallel.tex
+++ b/appendix/questions/concurrentparallel.tex
@@ -41,10 +41,10 @@ parallel processes communicate, the higher the level of sophistication
 required from the scheduler.
 As such, parallel computing's avoidance of interdependencies means that
 parallel-computing programs run well on the least-capable schedulers.
-In fact, a pure parallel-computing program can run successfully after
+In fact, a pure data-parallel program can run successfully after
 being arbitrarily subdivided and interleaved onto a uniprocessor.\footnote{
-	Yes, this does mean that data-parallel-computing programs are
-	best-suited for sequential execution.
+	Yes, this does mean that data-parallel programs are best-suited
+	for sequential execution.
 	Why did you ask?}
 In contrast, concurrent-computing programs might well require extreme
 subtlety on the part of the scheduler.
@@ -92,15 +92,33 @@ perspective and ``parallel'' by many taking the second perspective.
 }\QuickQuizEnd
 
 A third perspective considers concurrency to a logical manifestation of
-the cource code and parallelism to be a physical manifestation of running
+the source code and parallelism to be a physical manifestation of running
 that code on actual hardware.
-This perspective might have the virtue of being easy to teach, but
-it seems to be a bit lacking from a practical viewpoint.
+But then what should we make of user applications that spawn variable
+numbers of threads based on the number of CPUs available?
+Are these applications concurrent when running on a single CPU and
+parallel when running on multiple CPUs?
+If those applications are still concurrent rather than parallel
+even on multiple CPUs, what if they use facilities such as
+\co{sched_setaffinity()} to bind each of their threads to specified CPUs?
+And then does it make a difference whether such applications hard-code
+the CPU numbers on the one hand or compute the CPU numbers based on
+the available CPUs on the other?
+And if those applications are still merely concurrent, what if they
+refuse to run if fewer than (say) four CPUs are available?
+And what if the bottleneck is something other than CPUs, as discussed in
+\cref{sec:datastruct:Hash-Table Performance}?
+While these questions and variations on them are being carefully
+considered in the light of experience running such applications in
+production, please note that the scalability graphs in this book fully
+justify the word ``Parallel'' in the title.
+
+In short, this perspective might have the virtue of being easy to teach,
+but it seems to be a bit lacking from a practical viewpoint.
 
 Which is just fine.
-No perspective that humankind might take carries any weight against
-the objective universe, not even perspectives dividing multiprocessor
-programs into categories such as ``concurrent'' and ``parallel''.
+After all, no human perspective carries any weight against the objective
+universe.
 
 This categorization failure does not necessarily mean such perspectives
 are useless, but rather that you should take on a suitably skeptical
@@ -110,4 +128,4 @@ As always, use a give perspective where it applies and ignore it otherwise.
 In fact, it is likely that new perspectives will arise in addition
 to parallel, concurrent, map-reduce, task-based, and so on.
 Some will stand the test of time, and some will not.
-In the meantime, good luck guessing which is which!
+Best wishes in your quest to guess which is which!