DCE Application Programming Guide

Application Programming With NonStop DCE
Threads
HP NonStop DCE Application Programming Guide429551-003
3-6
Addressing the Thread Stack
program can get unexpected results if two different threads use these functions
without synchronizing their calls.
Consider using a mutex to protect implicit context maintained by a standard library,
for example by bracketing a series of library calls with the lock and unlock of a
mutual exclusion (mutex) operation. This technique should be considered only in a
short-lived context.
Standard libraries that use an explicit handle to identify the intended context on
each call can be used without interference between threads. File operations that
use file descriptors follow this model.
Some libraries allow multiple contexts but do not support explicit context
identification on all calls. Instead, the library allows the caller to establish a current
context for the process. With these libraries, the application is responsible for
ensuring that the correct context is made current while a thread is executing. For
example, the TMF transaction-demarcation API uses this method, relying on an
implicit current transaction for the process.
Addressing the Thread Stack
Memory for function variables that are not declared static is allocated from the thread-
private stack for an application.
For a TNS application, this memory is addressable only while the thread is
executing; it is not addressable by other threads. Attempting to read or write
variables located in another thread’s stack causes unpredictable results.
All program data that is to be shared by multiple threads must be either external
data, static internal data, or data allocated from the heap. This data should be
protected by a mutex, as appropriate.
For a TNS/R or TNS/E application, this memory is addressable by other threads,
and the data should be protected by a mutex, as appropriate.
Making Process-Blocking Calls
Jacket routines are provided for converting process-blocking Guardian calls into
thread-blocking operations because a call to a file or SQL/MP operations can cause
the entire process to block. When a thread calls a Guardian procedure that blocks the
process, all other threads in the process are prevented from executing, thus reducing
application concurrency. If a thread is blocked for a significant period of time, it can
delay or even prevent the execution of time-critical run-time functions.
Examples of programs that can block include:
RPC client programs that read input from a terminal. These programs can wait
indefinitely for input.
Pathway servers. These programs can wait indefinitely while reading $RECEIVE.