DOC: do not mention ThreadedGenerateData, and other review fixes

Author: dzenanz

SoftwareGuide/Latex/Architecture/SystemOverview.tex

@@ -473,15 +473,14 @@ \subsection{Multi-Threading}
 the filter's user or downstream filter in the pipeline. The best place for
 invoking \code{this->DynamicMultiThreadingOff();} is the filter's constructor.
 
-In image filters and other descendants of `ProcessObject`, method
-`SetNumberOfThreads` has been renamed into `SetNumberOfWorkUnits`.
-For `MultiThreaderBase` and descendants, `SetNumberOfThreads` has been
-split into `SetMaximumNumberOfThreads` and `SetNumberOfWorkUnits`.
-Load balancing is possible when `NumberOfWorkUnits` is greater
-than the number of threads. In most places where number of threads was
-being manipulated before, work units shoud be accessed or changed now.
-`MaximumNumberOfThreads` should not generally be changed, except when
-testing performance and scalability, profilng and sometimes debugging code.
+In image filters and other descendants of \code{ProcessObject}, method
+\code{SetNumberOfWorkUnits} controls the level of parallelism.
+Load balancing is possible when \code{NumberOfWorkUnits} is greater
+than the number of threads. In most places where developer would like to
+restrict number of threads, work units should be changed instead.
+\doxygen{MultiThreaderBase}'s \code{MaximumNumberOfThreads} should not
+generally be changed, except when testing performance and scalability,
+profiling and sometimes debugging code.
 
 The general philosophy in ITK regarding thread safety is that accessing
 different instances of a class (and its methods) is a thread-safe operation.

SoftwareGuide/Latex/DevelopmentGuidelines/WriteAFilter.tex

@@ -473,21 +473,16 @@ \section{Threaded Filter Execution}
 
 Multi-threading requires caution when performing I/O (including using
 \code{cout} or \code{cerr}) or invoking events. A safe practice is to allow
-only thread id zero to perform I/O or generate events. (The thread id is
-passed as argument into \code{ThreadedGenerateData(Region, ThreadId)}).
+only the invoking thread to perform I/O or generate events.
 If more than one thread tries to write to the same place at the same time,
 the program can behave badly, and possibly even deadlock or crash.
 
-In ITK version 5.0, `DynamicThreadedGenerateData` signature was introduced.
-This allows number of pieces (output regions) to be processed to be different,
-usually bigger than the number of real threads executing the work. In turn,
-this allows load balancing. The number of pieces has been renamed into
-work units, and the name `threads' is now reserved for real threads,
-as exposed by \doxygen{MultiThreaderBase} and descendants.
-
-Filters which need thread identifier (id) should implement the
-\code{ThreadedGenerateData(Region, ThreadId)} method and call
-\code{this->DynamicMultiThreadingOff();} in the filter's constructor.
+\code{DynamicThreadedGenerateData} signature allows number of pieces
+(output regions) to be processed to be different, usually bigger than the
+number of real threads executing the work. In turn, this allows load
+balancing. The number of work units controls filter parallelism,
+and the name `threads' is reserved for real threads as exposed by
+\doxygen{MultiThreaderBase} and its descendants.