DCE Application Programming Guide

Application Programming With NonStop DCE
Threads
HP NonStop DCE Application Programming Guide—429551-003
3-13
Single Versus Multiple Application Threads
Single Versus Multiple Application Threads
DCE programs can be classified by the way the application uses threads. The classes,
in the order of increasing complexity, are:
•
Programs With a Single Application Thread on page 3-13
•
Programs With Multiple Independent Application Threads on page 3-14
•
Programs With Multiple Interdependent Application Threads on page 3-15
Programs With a Single Application Thread
Externally, programs of this type appear to be standard, sequential (nonthreaded)
programs. The program begins execution in the main() procedure; it then calls other
procedures that, in turn, can call other procedures. Some of these procedures can be
library functions, and others can be remote procedure calls.
Each procedure executes sequentially and returns to its caller. The program eventually
finishes when it returns from the main() procedure.
This type of program includes simple DCE client programs.
When developing a DCE program with a single application thread, the application
designer needs to be aware of the interaction between the application thread and the
DCE run-time threads. These considerations are summarized in Table 3-3.
Designers of single-threaded applications can ignore certain concerns that apply to
multithreaded applications:
•
Process resources can be used freely.
No synchronization needs to be done. The application can freely use the process
resources (process and module globals, the heap, file descriptors, SQL cursors,
the signal mask, and so on). Mutexes and condition variables are not needed.
•
Standard libraries can be used freely.
The program does not need to be concerned about sharing access to library data,
including implicit context maintained across multiple library calls. For example, the
Table 3-3. Threading Considerations for a Single Application Thread
Consideration Summary
Making process-
blocking calls
Process-blocking calls can prevent execution of time-critical run-
time functions.
Using nowait input or
output
Programs cannot call AWAITIO or AWAITIOX with -1 as a file
parameter.
Yielding control Consider using pthread_yield() to allow run-time threads to
execute.
Spawning a new
process
Be careful when using one of the fork, exec, or tdm_spawn
sets of functions.