CORBA 2.6.1 Programmer's Guide for C++

Multithreading in Server Implementations
The behavior of the ORB with regard to multithreading depends on the setting of the threading policy in the POA. If the threading policy is set to
SINGLE_THREAD_MODEL, client requests are processed sequentially. Although multiple ORB threads might still be used, only one thread is
active on the POA at any given time.
If you use the default POA threading policy (ORB_CTRL_MODEL), requests can be processed concurrently, in multiple threads. The NonStop
CORBA ORB implements ORB_CTRL_MODEL with the thread-per-request model; that is, the POA will spawn additional threads as necessary
to handle additional requests, up to the maximum number of available servant threads.
The maximum number of servant threads available in a process defaults to 4097. This value can be changed with the environment variable
max_threads key in the server's profile@ORB entity. (Any value set in the environment variable overrides the setting in profile@ORB.) The
effective maximum number of threads in a server depends also on the size of each thread's stack (set by the
stack_size key in profile@ORB)
and the number of NonStop Kernel threads available in a processor.
With ORB_CTRL_MODEL, the POA initially creates a single thread to handle requests for objects in a server. When a new request arrives, the
POA either reuses an existing thread from the thread pool or spawns a new thread (if the thread pool is empty and the maximum number of
threads has not been reached) to handle the new request. For a new or reused thread to be activated, the thread processing the original request
must have become blocked or have explicitly released control of the processor. If the thread does not release control of the processor, the POA
thread cannot run and spawn or reuse a thread.
By using the ORB_CTRL_MODEL threading policy, servers can take advantage of multithreading without doing any explicit programming. In
certain situations, however, you might also find it desirable to make a server explicitly spawn new threads. Such threads can coexist with POA-
spawned threads. When doing explicit multithreading in server programs, keep the following points in mind:
Do not make process-blocking calls from a thread. Such calls defeat the purpose of a multithreaded process because the whole process
is blocked for the duration of the call. The SQL/MP and SQL/MX products do not support threads; therefore, all SQL calls are process-
blocking calls.
Operations directed to distributed objects are thread-blocking; nowait file I/O operations are also thread-blocking. Such operations block
only the calling thread, rather than the whole process. A well-designed multithreaded program makes use of thread-blocking operations
but not process-blocking operations.
Multiple active requests for the same object can be dispatched within multiple threads at the same time. Therefore, you must code such
portions as thread-safe (reentrant) code, protecting the object from access by more than one thread at a time. The vthread API
provides a
mutex mechanism for thread-safe programming.
NonStop CORBA provides jacket procedures for some Guardian calls, which essentially convert process-blocking calls to thread-
blocking calls. Such jacket procedures are available for some TS/MP and TMF calls. For more information about these jacket
procedures, see the Open System Services Programmer's Guide (Section 11).
Using the NonStop CORBA Portable Threading (vthread) API
As part of its portability and event framework, NonStop CORBA provides an object-oriented, portable application programming interface (API) for
multithreading. This API is implemented as a set of jacket procedures built upon the Standard POSIX Threads pthread API. With this
programming interface (called vthread), you can perform the following operations:
Create a thread
Yield control of the processor
Wait for other threads to complete
Cancel a thread
Save and retrieve thread-specific data
Also provided are two concurrency-control mechanisms: mutexes and condition variables. For mutexes, you can perform the following
operations:
Create a mutex
Lock a mutex
Unlock a mutex
Test a mutex
For condition variables, you can perform the following operations:
Create a condition variable
Wait on a condition variable
Signal availability of a condition variable
Broadcast availability of a condition variable
These operations are implemented by the Fw_Thread class, defined in the header file vthread.h in the $NSD_ROOT/include/nsdevent product