Add regression verification script

[ctsim.git] / doc / ctsim-algorithms.tex

diff --git a/doc/ctsim-algorithms.tex b/doc/ctsim-algorithms.tex
index 504aba11397ed8a4c865b222a068b63438decd24..b9ac22fb3687e6b67c37e0655045d025454bdec6 100644 (file)
--- a/doc/ctsim-algorithms.tex
+++ b/doc/ctsim-algorithms.tex
@@ -104,16 +104,9 @@ running on a SMP computer, and \ctsim\ is directed to perform
 reconstruction, rasterization, or projections, \ctsim\ will spawn
 a \emph{Background Supervisor} thread. This supervisor thread then
 creates a \emph{Supervisor Event Handler} (supervisor).  The
 reconstruction, rasterization, or projections, \ctsim\ will spawn
 a \emph{Background Supervisor} thread. This supervisor thread then
 creates a \emph{Supervisor Event Handler} (supervisor).  The

-supervisor communicates with the rest of \ctsim\ by using message
-passing to avoid issues with re-entrant code.
-
-Though the various threads do not directly call each other, it is
-prudent to lock the class data structures with \emph{Critical
-Sections}. Critical sections lock areas of code and prevent more
-than one thread to access a section of code at a time. This is
-used when maintaining the tables of worker threads in the
-supervisor and also when maintaining the tables of supervisors in
-the background manager.
+supervisor communicates with the rest of graphical user interface
+of  \ctsim\ by using message passing to avoid issues with
+re-entrant code.

 
 The supervisor registers itself via message passing with the
 \emph{Background Manager} which will display the execution
 
 The supervisor registers itself via message passing with the
 \emph{Background Manager} which will display the execution


@@ -125,17 +118,22 @@ supervisor directing the supervisor to cancel the calculation.
 After registering with \ctsim\ components, the supervisor creates
 \emph{Worker Threads}. These worker threads are the processes that
 actually perform the calculations. By default, \ctsim\ will create
 After registering with \ctsim\ components, the supervisor creates
 \emph{Worker Threads}. These worker threads are the processes that
 actually perform the calculations. By default, \ctsim\ will create

-one worker thread for every CPU in the system. The workers
-communicate with the supervisor via message passing. As the
-workers complete unit blocks, they send progress messages to the
-supervisor. The supervisor then sends progress messages to
-background manager which displays a gauge of the progress.
-
-After the workers have completed their tasks, they send a status
-message to the supervisor. When all the workers have finished, the
-supervisor will kill the worker threads. The supervisor then
-collates the work units from the workers and creates a new \ctsim\
-window to display the finished work.
+one worker thread for every CPU in the system. As the workers
+complete unit blocks, they notify the supervisor. The supervisor
+then sends progress messages to background manager which displays
+a gauge of the progress.
+
+As the worker threads directly call the supervisor, it is crucial
+to lock the class data structures with \emph{Critical Sections}.
+Critical sections lock areas of code and prevent more than one
+thread to access a section of code at a time. This is used when
+maintaining the tables of worker threads in the supervisor.
+
+After the workers have completed their tasks, they notify the
+supervisor. When all the workers have finished, the supervisor
+kills the worker threads. The supervisor then collates the work
+units from the workers and sends a message to \ctsim\ to create a
+new window to display the finished work.

 
 The supervisor then deregisters itself via messages with the
 background manager and the document. The background manager
 
 The supervisor then deregisters itself via messages with the
 background manager and the document. The background manager


@@ -155,8 +153,9 @@ This structure may seem more complex than is necessary, but it has
 several advantages:
 
 \begin{itemize}
 several advantages:
 
 \begin{itemize}

-\item Since the various threads do not call objects in other threads, problems
-with re-entrant code are eliminated.
+\item Since the background threads do not directly call objects in the graphical
+user interface thread, problems with re-entrant code in the
+graphical interface are eliminated.

 \item A supervisor can parallel process with any number of worker threads
 to take advantage of potentially large numbers of CPU's in SMP
 computers.
 \item A supervisor can parallel process with any number of worker threads
 to take advantage of potentially large numbers of CPU's in SMP
 computers.


@@ -175,14 +174,14 @@ include:
 results. When the worker threads finish, the supervisor allocates
 memory for the final result and collates the results for the
 workers. This collation results in a doubling of the memory
 results. When the worker threads finish, the supervisor allocates
 memory for the final result and collates the results for the
 workers. This collation results in a doubling of the memory

-requirements. Of course, after collation the supervisor
-deallocates the memory used by the workers.
+requirements. Of course, after collation the supervisor releases
+the memory used by the workers.

 \item Slower execution on single CPU systems. \\
 \item Slower execution on single CPU systems. \\

-The message passing between threads and collation
-of results for worker threads adds overhead compared to simply
-calculating the result directly in the foreground. On single CPU
-systems this results in slower processing compared to foreground
-processing. On dual-CPU and greater SMP systems, though, the
-advantage of using multiple CPU's in parallel exceeds the overhead
-of background processing.
+Creating multiple threads, sending progress messages to the
+background manager, and collation of results for worker threads
+adds overhead compared to simply calculating the result directly
+in the foreground. On single CPU systems this results in slower
+processing compared to foreground processing. On dual-CPU and
+greater SMP systems, though, the advantage of using multiple CPU's
+in parallel exceeds the overhead of background processing.

 \end{itemize}
 \end{itemize}