CORBA 2.6.1 Programmer's Guide for Java

Chapter 8. Writing Multithreaded Applications
Chapter 8. Writing Multithreaded Applications
Overview of Multithreading
Multithreading in Client Applications
Multithreading in Server Implementations
This section describes how to make appropriate threading decisions and write multithreaded NonStop CORBA applications.
Java programmers should use standard Java multithreading in NonStop CORBA applications.
For several examples of explicit multithreading in a NonStop CORBA application, see the Bank sample application. The client wrapper uses
mutexes. The feed program includes several uses of multithreading. Multithreading in the feed program reduces the number of processes that
are needed to generate workload for the application.
Overview of Multithreading
Multithreading is a programming paradigm that enables logically concurrent execution. A thread is a sequence of running code that coexists
with other threads in the same address space. Each thread has its own execution stack, but shares the process instruction space with other
threads. Having multiple threads in a process means that there are many apparently simultaneous points of execution. Multithreading simplifies
programming tasks by allowing you to write a single code sequence as if it were alone and run as many threads. By writing different threads to
handle different tasks, you can easily divide the process space. Multithreading can also increase the throughput of a process without incurring
the overhead of creating multiple processes.
The NonStop CORBA ORB itself is multithreaded, and it provides automatic multithreaded dispatching of requests to servants through its
implementation of the default POA threading policy, ORB_CTRL_MODEL. The same servant can be accessed by multiple threads. You can also
explicitly create additional threads in your applications. In a distributed NonStop CORBA application, you can use multithreading in the client, the
server, or both. You can use multithreading with or without server pools.
Some applications lend themselves better to multithreading than others. Multithreading can be useful when:
Interacting with another object or process that may be slow in responding
Interacting with a user who may not respond immediately
Note:
On NonStop systems, threads are not run in separate processors. To take advantage of parallel processing, use
separate processes rather than threads.
Multithreading on NonStop systems is non-preemptive.
Multithreading in Client Applications
One typical use of multithreading in NonStop CORBA client programs is to issue concurrent requests to one or more objects. When
multithreading is not used, operations are synchronous. That is, when a client performs an operation on an object, it must wait for the response
to arrive before doing any further processing. When a client application creates multiple threads, each thread can perform operations and thus
have concurrent outstanding requests.
The
feed program that is part of the Bank sample application contains a multithreaded NonStop CORBA client program.
Note:
You can use the Dynamic Invocation Interface (DII) instead of multithreading to issue asynchronous requests. In
some situations, this may be a desirable alternative to multithreading. However, using the dynamic invocation
interface generally requires more programming effort than does explicit multithreading.
Multithreading in Server Implementations
The behavior of the ORB with regard to multithreading depends on the setting of the threading policy in the POA. When 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.
When 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.