| blob | 3b60439dfa73dffe8b4b7aaf2fa48e49c7c22a08 |
2 <html>
4 <head>
6 </head>
8 <body>
9 <!-- -->
12 <p align="left">This documents keeps track of the TAO's <a href="#RT Corba Development Status">Real-Time CORBA Development Status</a> , and a description of the <a href="#Release Notes">Release
13 Notes</a> for our implementation. For any comment or question on a specific aspect of RT CORBA you can contact the responsible as listed in the <a href="#RT Corba Development Status">Real-Time CORBA Development Status</a>,
19 <p>The scope of this brief document is to keep track of the progress of the
20 RT-CORBA implementation, and to let the user understand what is already in place
21 what will be soon available and what will not be supported. <a href="#Table 1 - Status of the feature described in the RT CORBA Spec.">Table
23 spec. and their status respect to our implementation. <a href="#Table 2 - Feature needed to Enable RT-CORBA">Table
25 that are needed to "enable" our RT-CORBA implementation, and at last <a href="#Table 3 - Issue to be shortly addressed">Table
29 <p style="margin-left: 0; margin-right: 0; margin-top: 0; margin-bottom: 5" align="center"><b><a name="Table 1 - Status of the feature described in the RT CORBA Spec.">Table
31 Status of the feature described in the RT CORBA Spec. </a></p>
33 <center>
35 <tr>
40 </tr>
41 <tr>
46 Spivak</a></td>
47 </tr>
48 <tr>
53 Pyrali</a></td>
54 </tr>
55 <tr>
57 Mappings</td>
62 Spivak</a></td>
63 </tr>
64 <tr>
69 Spivak</a></td>
70 </tr>
71 <tr>
76 Spivak</a></td>
77 </tr>
78 <tr>
83 </tr>
84 <tr>
89 </tr>
90 <tr>
95 Pyrali</a></td>
96 </tr>
97 <tr>
102 Spivak</a></td>
103 </tr>
104 <tr>
109 Spivak</a></td>
110 </tr>
111 <tr>
116 Spivak</a></td>
117 </tr>
118 <tr>
123 Spivak</a></td>
124 </tr>
125 </table>
126 </center>
127 </div>
129 <p><b>Real-Time ORB - </b>Extension to the CORBA::ORB interface that provides operations to create and destroy other constituents of a RT ORB.</p>
131 provides additional operation to support object level priority and
133 is derived from the POA interface so it support all the semantics prescribed for
134 a non RT-POA. </p>
136 intent of shielding the user from the different priority scheme that a RTOS
137 might use, providing a uniform representation system wide. RT-CORBA Priority
138 Mappings take care of mapping RTCORBA::Priority into native priorities. Right
141 CORBA::Current, and provide access to the CORBA Priority of the current thread.
142 Real Time CORBA Priority can be associated with the current thread by using this
143 interface.</p>
145 for the coordination of priorities across a system, that let set the priority at
146 which a servant executes. This two different model are <i>Client Propagated
149 designer to implement RT-CORBA system using priority models different from
150 either the Client Propagated or Server Declared. Priority Transforms are user
151 provided functions that map one RTCORBA::Priority value to another
152 RTCORBA::Priority value.</p>
153 <p><b>Mutex Interface - </b>Real-Time CORBA defines a Mutex interface, and two operation in the RTORB interface for creating and destroying such mutex. This mutex
154 should have the same priority inheritance scheme used by the ORB.</p>
156 Thread Pools, with or without lanes, and for creating Thread Pools Priorities.
157 Lanes are just sub-sets of threads at assigned different RTCORBA::Priority
161 made on a object reference. In particular a call to <font face="Courier New">validate_connection
165 bands that are in turn used to serve request depending on the priority model
166 used by the target object.</p>
168 private transport connection which will not be shared with other client-server
169 connections.</p>
171 the protocols on the client and server side of the ORB.</p>
172 <p align="center" style="margin-bottom: 5"><a name="Table 2 - Feature needed to Enable RT-CORBA">Table
175 <center>
177 <tr>
182 </tr>
183 <tr>
188 Corsaro</a></td>
189 </tr>
190 <tr>
195 Corsaro</a></td>
196 </tr>
197 <tr>
201 <td width="133" align="center" height="1"><a href="mailto:coryan@ece.uci.edu">Carlos O'Ryan</a></td>
202 </tr>
203 </table>
204 </center>
205 </div>
208 last stage of development. The collocation scheme has been changed because the
209 selection of the right proxy to use to perform a call, now has to be taken on a
210 call-per-call basis, to avoid interference between thread priorities. In
211 designing the new scheme we tried to reduce the memory footprint and the
212 overhead that the new scheme needs to introduce.</p>
216 This facilities were added to those policies.</p>
218 <p><b>Invocation Timeout - </b>Allows the setting of timeout that expire if an invocation doesn't complete in a given amount of time.</p>
222 <p align="center" style="margin-bottom: 5"><a name="Table 3 - Issue to be shortly addressed">Table
225 <center>
227 <tr>
231 </tr>
232 <tr>
237 </tr>
238 <tr>
242 </tr>
243 <tr>
247 </tr>
248 <tr>
252 </tr>
253 </table>
254 </center>
255 </div>
259 quite nasty. The class interface are pretty counter-intuitive, and the code that
260 deal with profile needs to be redesigned and re-implemented.</p>
262 written to show how to use RT CORBA's features, and to massively test the
263 behavior of the new stuff.</p>
265 to see the impact of the changes and to early individuate critical path and
266 bottlenecks.</p>
270 <p>We are currently working on implementing RT CORBA 1.0 specification in TAO. Our design is an extension of the <em>endpoint-per-priority</em> architecture mentioned in the <tt>Recently
271 Completed Work</tt> section below. In this design, codenamed <em>reactor-per-lane</em>, each threadpool lane owns a set of I/O resources, i.e., <tt>Reactor</tt>, <tt>Acceptor</tt>,
272 and <tt>Connector_Registry.</tt> Each request is serviced by a single thread without context switches, i.e., the same thread performs I/O and runs the servant code.
273 <p>Below there is a list of feature recently added to TAO, and in also a brief description of the main feature that characterize certain feature related to our implementation of
274 RT-CORBA.</p>
275 <ul>
276 <li>
278 <li>
280 <li>
282 <li>
284 <li>
286 <li>
288 <li>
290 <li>
292 <li>
294 <li>
296 <li>
297 <p style="line-height: 150%">Implemented Policy framework (defined in the Messaging specification, used in RT CORBA).
298 <li>
299 <p style="line-height: 150%">Added support for Real-time CORBA Priority and implemented two Priority Mappings: <tt>Linear</tt> and <tt>Direct</tt>.
300 <li>
301 <p style="line-height: 100%">Added support for end-to-end CORBA request priority preservation. This is achieved through <em>multiple listening endpoint</em> architecture, a.k.a. <em>endpoint-per-priority</em>,
302 on the server and a Client Priority Policy on the client. Following is a brief description of how this is implemented.
303 <p style="line-height: 100%">Server ORB uses multiple transport endpoints to accept connections from clients. Each transport endpoint has a priority, which is the priority of the
304 thread(s) servicing the endpoint as well as all connections it accepts. When a server ORB creates an IOR for one of its objects, it embeds all of the server's listening endpoints
305 along with their priorities into the object's IOR. Then, a client ORB selects the priority that best matches client's need (as specified by the Client Priority Policy) from those
306 offered by the server, and uses the corresponding transport endpoint specified by the server to obtain the desired level of service.
307 <p style="line-height: 100%">For more details and performance results for <em>endpoint-per-priority</em> architecture, see <a href="http://www.cs.wustl.edu/~marina/boeing.pdf">this
308 paper.</a> See <tt>TAO/tao/TAO.pidl</tt> for Client Priority Policy interface definition, and <tt>TAO/tests/Endpoint_Per_Priority</tt> for example of using priority preservation
309 in TAO.
311 <li>
312 <p style="line-height: 100%">Implemented reliable one-way requests, i.e., SyncScope Policy from the Messaging specification. This is relevant to RT CORBA because of the following
313 feature: setting SyncScope Policy to SYNC_NONE enables buffering of one-way requests in the client ORB. Request buffering can be used to optimize message throughput, possibly at
314 the expense of latency. ORB buffering behavior is controlled by the Buffering Constraint Policy, which is described next.
315 </ul>
317 <ul>
318 <li>
319 <p style="line-height: 100%">Added support for buffered one-way and asynchronous requests in the client ORB. Buffering Constraint Policy gives users control over queueing and
320 flushing of requests in the ORB. A combination of the following conditions for initiating buffer flush can be specified using this policy:
321 <ul>
322 <li>
324 <li>
326 <li>
328 <li>
330 <li>
332 </ul>
333 <p style="line-height: 100%">Also supported are out-of-band requests, i.e., requests that bypass buffers and are delivered to the server immediately.
334 <p style="line-height: 100%">Buffering Constraint Policy is a TAO-specific feature. See <tt>TAO/tao/TAO.pidl</tt> for policy interface definition and <tt>TAO/examples/Buffered_Oneways</tt>
335 and <tt>TAO/examples/Buffered_AMI</tt> directories for its use. For motivation and performance of buffered one-ways see <a href="http://www.cs.wustl.edu/~marina/boeing.pdf">this
336 paper.</a></p>
337 </li>
338 </ul>
340 <ul>
341 <li>
342 <p style="line-height: 100%">Location forwarding does not work properly with <em>endpoint-per-priority</em> model.</li>
343 </ul>
345 <ul>
346 <li>
347 <p style="line-height: 100%">Provide server-side RT CORBA implementation using a <em>queue-per-lane</em> approach. In this approach each threadpool lane owns a queue, while I/O
348 resources are being shared among all the threadpool lanes of the same priority within the server. Strategize TAO to use either <em>queue-per-lane</em> or <em>reactor-per-lane</em>
349 implementation, and compare the two.</li>
350 </ul>
352 </body>
354 </html>