|
К этому устройству также есть другие инструкции:
Фрагмент инструкции
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. If 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. 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
q
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
q
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
q
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
q
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. See the NonStop DCE Application
Programming Guide for more information about these jacket procedures.
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 NonStop DCE pthread API.
With this programming interface (called vthread), you can perform the following operations:
...Эта инструкция также подходит к моделям:
Компьютеры - HP NonStop L-Series (446.84 kb)