[omniORB] Multithreading mechanism

[Sai-Lai Lo]

>>>>> Yang Lingjia writes:

> Should I take it as that OmniOrb doesn't support thread pool mechanism?  :-)

No, not in the code distributed. A so-call 'thread pool' mechanism is
simply a selector thread plus a pool of threads blocking not on the socket
but an internal queue. It is not difficult to implement. It is a deliberate
decision not to implement this mechanism in the ORB.


> The reason for us to in favor of pool thread mechanism is that we need to
> initialize a pool of database connections at the startup stage of the
> system.  As we all know that initialization of database handler takes a
> long time.  This will reduce the waiting time of the clients and we can
> reuse the resources.  In the other words, if we use thread per connection
> mechanism, database handler will be released after the client
> disconnected.  If we use the thread pool mechanism, we can reuse the
> database handler.  Thread pool mechanism is more efficient compare to
> thread per connection because it allows sharing of threads among clients.

You can also initialise your database handlers as a resource pool (a queue
of handlers for instance). During the up-call from the ORB, your code grab
one handler from the pool. May be it has to block waiting for one to be
freed, or even make one up if none is available. The point here is that you
have complete and dynamic control on the no. of handlers to initialise at
any time and is completely independent of how the ORB manages its
threads. With thread pool, choosing the right number to initialise is no
better than guess work, unless your thread pool implementation can
dynamically adjust the no. of worker threads based on the no. of active
connections or requests at any time. Thread per connection is the most
straight forward dynamic adaptation to the load condition. Of course, when
the no. of connections greatly exceed the no. of threads the system can
reasonably support then the thread per connection breaksdown. But that
limit on any reasonable system runs up to a 4 digit number. 

I think there are good reasons to give applications more control on
allocating thread resources to client requests. Instead of first come first
serve, there may be a need to distinguish premium class clients from
ordinary clients. Under heavy load conditions you may want to keep the
response time to premium class clients low by dedicating a number of
threads to these clients. However, there are other ways to achieve the
same result, such as spawning off additional servers on other machines and
use CORBA's transparent location forwarding mechanism to separate out
premium and ordinary class clients.

> One more point, our clients need to initialize a few request to the
> server at one time.  It will have no problem with pool thread mechanism.
> For thread per connection, it needs to initialize a connection per
> request.

The difference here is not the no. of threads needed on the server side. Both
needs the same number of threads to service the requests. With thread-pool,
how do you know you've got sufficent no. of threads in the pool to serve
all the simultaneous requests from the same client plus all the other
activities from other clients? There has to be a trottle on the server side
to prevent itself from dedicating all its worker threads to requests coming
from one client. That means at some point some requests will not be served
until previous ones are completed. With thread per connection, the clients
do have to open more than one connections to the server. This may or may
not be an issue. It seems to me this is not an issue with a reasonably
modern platform.

Sai-Lai




-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND