Open System Services Programmer's Guide

Single Versus Multiple Application Threads
OSS threaded applications can be classified as follows, in order of increasing complexity:
• “Programs With a Single Application Thread” (page 431)
• “Programs With Multiple Independent Application Threads” (page 432)
• “Programs With Multiple Interdependent Application Threads” (page 432)
Programs With a Single Application Thread
Externally, programs with a single application thread behave like standard, sequential (nonthreaded)
programs. The program begins execution in the main() procedure; it then calls other procedures
that, in turn, can call still other procedures. This type of application includes simple OSS client
programs.
In single-threaded applications:
• Process resources can be used freely.
No synchronization is needed. The application can freely use process resources such as
process and module globals, the heap, file descriptors, SQL cursors, and the signal mask.
Mutexes and condition variables are not needed.
• Standard libraries can be used freely.
The application can share access to library data, including implicit context maintained across
multiple library calls. For example, the application thread can use the TMF transaction jacket
routines and no other thread can change the current transaction of the process.
• One application thread cannot block another from executing. Process-blocking operations
have minimal effect.
• One application thread cannot corrupt another.
The thread does not share its address space with any other application threads. The application
thread is protected by the address-space protection provided for the process, offering fault
isolation.
The following general threading considerations affect single-threaded applications but have less
effect than for processes with multiple application threads:
• Using process-blocking calls
Although process-blocking calls will not affect other will not affect other application threads,
they can interfere with time-critical threads.
• Isolating faults and yielding control
If the application thread can execute for long periods (more than a second) without relinquishing
control, the application might still need to use the sched_yield() function to allow
time-critical threads to execute.
These general threading considerations apply to single-threaded applications:
• Using nowait input or output as described in “Using Nowait Input or Output” (page 430).
• Spawning a process as discussed in “Spawning a New Process” (page 430).
Threaded Application Programming 431