Log:
Évaluations - 0, GPA: 0 ( )

Instructions HP, Modèle HP NonStop G-Series

Fabricant : HP
Taille : 476.87 kb
Nom Fichier :
Langue d'enseignement: en
Aller à la télécharger



Par ce dispositif a également d'autres instructions :

Facilité d'utilisation


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. 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
NSDOM_CFG_MAX_THREADS environment variable or the 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
q
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
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

...

Ce manuel est également adapté pour les modèles :
Ordinateurs - HP NonStop L-Series (476.87 kb)

Écrivez votre propre critique du dispositif



Texte du message
Votre nom :
Entrez les deux chiffres :
capcha





catégories