ChangeLogTag:Fri May 30 17:15:57 2003 Nanbor Wang <nanbor@cs.wustl.edu>

1 files changed, 116 insertions, 112 deletions

diff --git a/TAO/docs/configurations.html b/TAO/docs/configurations.html
index f396f608fd2..4f9907c7eef 100644
--- a/TAO/docs/configurations.html
+++ b/TAO/docs/configurations.html
@@ -66,16 +66,16 @@ Roadmap</h3>
         <li><a href="#tpc">Multiple threads, single ORB, thread-per-connection
             model.</a></li>
 
+        <li><a href="#tpool">Multiple threads, single ORB, TAO thread-pool model.</a></li>
+
+        <li><a href="#rtpool">Multiple threads, single ORB, Real-time CORBA thread-pool model.</a></li>
+
         <li><a href="#multiorb">Multiple threads, multiple ORBs,
             reactive model.</a></li>
 
         <li><a href="#multiorb-tpc">Multiple threads, multiple ORBs,
             thread-per-connection model.</a></li>
 
-        <li><a href="#tpool">Multiple threads, single ORB, TAO thread-pool model.</a></li>
-
-        <li><a href="#rtpool">Multiple threads, single ORB, Real-time CORBA thread-pool model.</a></li>
-
         <li><a href="#multiorb-tpool">Multiple threads,
             ORB-per-thread, thread-pool reactive model.</a></li>
 
@@ -284,7 +284,7 @@ The following are common ORB configurations used by TAO applications.<P>
 
           <td>This is the default configuration of TAO, where one
               thread handles requests from multiple clients via a
-              single Reactor. It is appropriate when the requests (1)
+              one Reactor. It is appropriate when the requests (1)
               take a fixed, relatively uniform amount of time and (2)
               are largely compute bound.</td>
         </tr>
@@ -319,7 +319,8 @@ The following are common ORB configurations used by TAO applications.<P>
         <tr>
           <th align=left>Options</th>
 
-          <td>The default settings should work just fine.  However,
+          <td>The default settings should work just fine (by default,
+              the <tt>-ORBReactorType</tt> is <tt>tp</tt>).  However,
               you can apply the following options to improve performance:<br>
               <tt>TAO_Advanced_Resource_Factory</tt>: <tt>-ORBReactorType
               select_st</tt>, <tt>-ORBInputCDRAllocator null</tt>
@@ -392,110 +393,6 @@ The following are common ORB configurations used by TAO applications.<P>
     <tt><a href="../performance-tests/Cubit/TAO/IDL_Cubit/">IDL_Cubit</a></tt>
     is a good example on using <i>multiple threads, thread-per-connection</i>
     configuration.<P>
-<li>
-    <P><B>Multiple threads, multiple ORB, reactive model.</B><a NAME="multiorb"></a></li><P>
-
-    <table BORDER=2 CELLSPACING=2 CELLPADDING=0 WIDTH="90%">
-      <tr>
-        <th align=left>Typical Use</th>
-
-        <td>In this configuration, there are multiple ORBs in a
-            process with multiple threads. Each thread handles requests
-            reactively.  This model is good for hard real-time applications that
-            require different thread priorities for the various
-            ORBs.</td>
-      </tr>
-
-      <tr>
-        <th align=left>Number of Threads</th>
-
-        <td>One thread for each ORB.</td>
-      </tr>
-
-      <tr>
-        <th align=left>Thread Creator</th>
-
-        <td>The main process (thread).</td>
-      </tr>
-
-      <tr>
-        <th align=left>Thread task</th>
-
-        <td>Service the requests from associating ORB.</td>
-      </tr>
-
-        <tr>
-          <th align=left>Synchronization considerations</th>
-
-          <td>Application servants needn't
-              be concerned with synchronizing their interactions if
-              there's no cross ORB/thread access.</td>
-        </tr>
-
-      <tr>
-        <th align=left>Options</th>
-
-        <td> The default settings just works fine. However, one could
-            use  <br><tt>TAO_Advanced_Resource_Factory</tt>: <tt>-ORBReactorType
-            "<em>which</em>"</tt>, for a thread-safe platform specific reactor.<br>
-            </td>
-      </tr>
-</table>
-<P>
-
-<li><B>Multiple threads, multiple ORBs, thread-per-connection model.</B><a
-    NAME="multiorb-tpc"></a></li><P>
-
-    <table BORDER=2 CELLSPACING=2 CELLPADDING=0 WIDTH="90%">
-      <tr align="left">
-      <th align=left>Typical Use
-      </th>
-
-      <td>This approach provides a range of thread priorities plus connections
-          that don't interfere with each others.</td>
-    </tr>
-
-    <tr>
-      <th align=left>Number of Threads</th>
-
-      <td>One thread for each ORB, plus one thread for each connection.</td>
-    </tr>
-
-    <tr>
-      <th align=left>Thread Creator</th>
-
-      <td>Main threads creates threads running ORBs. They, in turns,
-          create connection handling threads.</td>
-    </tr>
-
-    <tr>
-      <th align=left>Thread task</th>
-
-      <td>There are threads running ORB's event loops which handle
-          connection requests and handler threads which service
-          requests from established connections.</td>
-    </tr>
-
-        <tr>
-          <th align=left>Synchronization considerations</th>
-
-          <td> To avoid race conditions, application servants may need to
-            synchronize their methods if multiple clients can access
-            them concurrently.</td>
-        </tr>
-
-    <tr>
-      <th align=left>Options</th>
-
-      <td><tt>TAO_Server_Strategy_Factory</tt>:
-          <tt>-ORBConcurrency thread-per-connection</tt></td>
-    </tr>
-</table>
-
-<P>
-<tt><a href="../performance-tests/Cubit/TAO/MT_Cubit/">MT_Cubit</a>
-</tt> is a good example on using <i>multiple threads,
-multiple ORBs, and thread-per-connection</i> configuration.<P>
 
 <li>
     <a NAME="tpool"></a><B>Multiple threads, single ORB, TAO thread-pool model.</B></li><P>
@@ -507,7 +404,7 @@ multiple ORBs, and thread-per-connection</i> configuration.<P>
         <td>This model implements a highly optimized, TAO-specific thread pool that minimizes
             context switching and thread creation costs.  In this
             model, the programmer is responsible of spawning a group
-            of threads, start up the ORB and then instruct all the
+            of threads, creating an ORB instance, and then instructing all the
             threads to run the ORB event loop.  When a request comes in, one
             of these waiting threads in the pool will handle the
             request.</td>
@@ -543,7 +440,9 @@ multiple ORBs, and thread-per-connection</i> configuration.<P>
       <tr>
         <th align=left>Options</th>
 
-        <td> The default settings work great for this</td>
+        <td> The default ORB settings support this concurrency
+            configuration, though you'll need to spawn the extra
+            threads in the pool explicitly.</td>
       </tr>
     </table>
     <P>
@@ -612,6 +511,111 @@ multiple ORBs, and thread-per-connection</i> configuration.<P>
 <P>
 
 <li>
+    <P><B>Multiple threads, multiple ORBs, reactive model.</B><a NAME="multiorb"></a></li><P>
+
+    <table BORDER=2 CELLSPACING=2 CELLPADDING=0 WIDTH="90%">
+      <tr>
+        <th align=left>Typical Use</th>
+
+        <td>In this configuration, there are multiple ORBs in a
+            process with multiple threads. Each thread handles requests
+            reactively.  This model is good for hard real-time applications that
+            require different thread priorities for the various
+            ORBs.</td>
+      </tr>
+
+      <tr>
+        <th align=left>Number of Threads</th>
+
+        <td>One thread for each ORB.</td>
+      </tr>
+
+      <tr>
+        <th align=left>Thread Creator</th>
+
+        <td>The main process (thread).</td>
+      </tr>
+
+      <tr>
+        <th align=left>Thread task</th>
+
+        <td>Service the requests from associating ORB.</td>
+      </tr>
+
+        <tr>
+          <th align=left>Synchronization considerations</th>
+
+          <td>Application servants needn't
+              be concerned with synchronizing their interactions if
+              there's no cross ORB/thread access.</td>
+        </tr>
+
+      <tr>
+        <th align=left>Options</th>
+
+        <td> The default settings just works fine. However, one could
+            use  <br><tt>TAO_Advanced_Resource_Factory</tt>: <tt>-ORBReactorType
+            "<em>which</em>"</tt>, for a thread-safe platform-specific reactor.<br>
+            </td>
+      </tr>
+</table>
+<P>
+
+<li><B>Multiple threads, multiple ORBs, thread-per-connection model.</B><a
+    NAME="multiorb-tpc"></a></li><P>
+
+    <table BORDER=2 CELLSPACING=2 CELLPADDING=0 WIDTH="90%">
+      <tr align="left">
+      <th align=left>Typical Use
+      </th>
+
+      <td>This approach provides a range of thread priorities plus connections
+          that don't interfere with each others.</td>
+    </tr>
+
+    <tr>
+      <th align=left>Number of Threads</th>
+
+      <td>One thread for each ORB, plus one thread for each connection.</td>
+    </tr>
+
+    <tr>
+      <th align=left>Thread Creator</th>
+
+      <td>Main threads creates threads running ORBs. They, in turns,
+          create connection handling threads.</td>
+    </tr>
+
+    <tr>
+      <th align=left>Thread task</th>
+
+      <td>There are threads running ORB's event loops which handle
+          connection requests and handler threads which service
+          requests from established connections.</td>
+    </tr>
+
+        <tr>
+          <th align=left>Synchronization considerations</th>
+
+          <td> To avoid race conditions, application servants may need to
+            synchronize their methods if multiple clients can access
+            them concurrently.</td>
+        </tr>
+
+    <tr>
+      <th align=left>Options</th>
+
+      <td><tt>TAO_Server_Strategy_Factory</tt>:
+          <tt>-ORBConcurrency thread-per-connection</tt></td>
+    </tr>
+</table>
+
+<P>
+<tt><a href="../performance-tests/Cubit/TAO/MT_Cubit/">MT_Cubit</a>
+</tt> is a good example on using <i>multiple threads,
+multiple ORBs, and thread-per-connection</i> configuration.<P>
+
+<li>
     <B>Multiple threads, multiple ORBs, thread-pool model.</B><a NAME="multiorb-tpool"></a>
 </li><P>