X-Git-Url: http://git.kpe.io/?p=ctsim.git;a=blobdiff_plain;f=doc%2Fctsim-algorithms.tex;h=b9ac22fb3687e6b67c37e0655045d025454bdec6;hp=504aba11397ed8a4c865b222a068b63438decd24;hb=d16eb37cbc73f67fc29a60645e0b1ac7fe32767e;hpb=a4b718a2681d65cb56e62400cec28bc09f9509e1

diff --git a/doc/ctsim-algorithms.tex b/doc/ctsim-algorithms.tex
index 504aba1..b9ac22f 100644
--- 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
-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
@@ -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
-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
@@ -155,8 +153,9 @@ This structure may seem more complex than is necessary, but it has
 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.
@@ -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
-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. \\
-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}