background image
Bionic Buffalo Tech Note #49: Thread Support in the 
 Object Request Broker
max connections + max requests + 2
additional threads. (The possible total number of open sockets required can be
max connections + number of application threads + 1
in this design.)
Each local servant is associated with a Portable Object Adapter, or POA. When each POA is created,
that POA is associated with a thread policy. There are three possible thread policy values:
. In this model, the POA and its servants may
simultaneously process requests from any or all application threads and from any or all
remote request threads. Servants must be thread-safe.
. In this model, for each POA, no
more than one thread my invoke POA or thread operations at a given time. If a POA is in
use by one thread, then any other thread attempting to use that POA will block until the
first thread no longer uses that POA. Servants may not be thread-safe. However, because
a servant may recursively invoke itself, or may invoke other servants of the same POA,
servants may need to be reentrant. Under some circumstances, there also may be a
potential for deadlock, if servants of different POAs are prevented from calling one
another due to the single-thread restriction.
. In this model, all POAs with this
policy, taken together, are allowed use by only one thread at a time. The result is similar
to what would occur if all their servants were combined into one single-thread POA. The
potential for deadlock among servants of POAs using this policy is eliminated, but
reentrant code still may be necessary.
Although thread dispatch deadlocks might be prevented, there remains the possibility of resource
deadlocks in servants which maintain or alter any sort of state information. Unless stateless methods
are used, the programmer must still be careful about resource deadlocks. For example, if one method
has exclusive access to a file needed by another method, any serialization or queueing of the second
method's request is the responsibility of the servant or application programmer, not of the ORB or
, each type of thread creates has the same priority, although the priorities are
configurable at build time and may differ from type to type. Initializers for threads, mutexes, and
conditions use default values (without attributes). Developers requiring more control over threads and
resource allocation should use an ORB (such as 
) which supports the Real-Time CORBA
Developers requiring more control over connections and over how messages and requests are
processed should use an ORB (such as 
) which supports the CORBA Messaging specification.
Page 3 of 4