Threading

Threading Overview

Multithreading is a programming facility that enables concurrent programming. A thread is a lightweight process that coexists with other threads in the same address space. Each thread has its own set of CPU registers and its own stack. It shares the process instruction space with other threads. Having multiple threads in a process means that there are many "simultaneous" points of execution. Although NonStop DOM application programmers are generally unaware of it, the NonStop DOM ORB uses threading internally. A NonStop DOM application programmer may also decide to use explicit threading.

The main purpose of threads is to increase the throughput of a process by using parallelism. Some applications lend themselves better than others to be implemented in a multithreaded fashion. In a distributed NonStop DOM application, you can use threads in the client, the server, or both.

Threading 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
• Interacting with slow devices

Threading in Client Applications

One typical use of threading in NonStop DOM client programs is to issue concurrent requests to one or more objects. When threading is not used, method requests are synchronous. That is, when a client issues a method request to 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 issue method requests and thus have concurrent outstanding requests.

The sample program $NSD_ROOT/samples/bank/feed contains a multithreaded NonStop DOM client program.

Note: You can use the dynamic invocation interface instead of threading to issue asynchronous requests. Depending on the situation, this may be a desirable alternative to threading. Be aware, that using the dynamic invocation interface generally requires more programming effort.

Threading in Server Implementations

If you use the default POA threading policy, no thread programming is required. The POA will spawn additional threads as necessary to handle additional requests. The POA initially creates a single thread to handle requests for objects in a server. If a new request arrives before an outstanding request has completed, the POA may spawn another thread to handle the new request. For this to occur, 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 a new thread.

In certain situations, you may find it desirable to make a server spawn new threads. Such threads can coexist with POA-spawned threads.

Keep the following points in mind when dealing with multithreaded servers:

• 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. Tandem's NonStop SQL/MP product does not support threads; therefore, all SQL calls are process-blocking calls.
  
• File I/O or method requests for remote objects are examples of thread-blocking calls. Such calls block only the calling thread, not the whole process. A well-designed multithreaded program makes use of thread-blocking calls but not process-blocking calls.
  
• NonStop DOM provides jackets for some Guardian calls, which essentially convert process-blocking calls to thread-blocking calls. Jackets are available for some NonStop TS/MP and NonStop TM/MP calls. See the NonStop DCE Application Programming Guide for more information about jackets.
  

NonStop DOM Portable Threading Interface

NonStop DOM provides an object-oriented, portable application programming interface (API) to threads. With this programming interface, you can perform the following thread operations:

• Create a thread
• Change your thread's priority
• Yield control of the processor
• Wait for other threads to complete
• Cancel a thread
• Manipulate thread specific data

Also provided are two concurrency control mechanisms: mutexes and condition variables. For mutexes, you may perform the following operations:

• Create a mutex
• Lock a mutex
• Unlock a mutex
• Test a mutex

For condition variables, you may 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