Open System Services Programmer's Guide

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 329).
• Spawning a process as discussed in “Spawning a New Process” (page 331).
Programs With Multiple Independent Application Threads
Programs containing multiple threads can improve performance by providing concurrent execution.
An application thread is independent if it does not explicitly share application resources that exist
in the process environment, such as application file opens, SQL cursors, or modifiable application
data structures.
This type of application includes simple OSS servers that maintain the application state in a
database. Such a server simplifies server design because then application state does not need to
be maintained in the server and thus most servers can be context-free. In cases where context must
be maintained across multiple requests, the context is generally private to the client and should
not be shared.
“Threading Considerations” (page 328) describes some considerations for developing an application
with multiple application threads.
Programs With Multiple Interdependent Application Threads
An application thread is interdependent if it shares application resources that exist in the process
environment, such as application file opens, SQL cursors, and modifiable application data structures.
Applications with multiple interdependent application threads must synchronize access to the shared
application resources.
332 Using the Standard POSIX Threads Library