OSF DCE Application Development Guide--Introduction and Style Guide

Threads
These thread safety issues arise in the following two contexts for DCE applications:
• Even when application code is not itself multithreaded (for example, client code that
does not make any explicit pthread API calls), both client and server applications
are still multithreaded as a result of threads created by the RPC runtime. While such
single-threaded application code need not itself be reentrant, it must still avoid
blocking the entire process, and it must take care that any library routines that it calls,
which may also be called by runtime-created threads, are reentrant.
• When application code is itself multithreaded (which is the default for server
manager code), it must, in addition to obeying the rules above), also be reentrant; all
access to shared objects must be protected by locks.
Obviously, providing for the second condition in explicitly multithreaded code is the
application’s responsibility. The pthread API provides a set of facilities that can be used
for this purpose. To provide for the first condition, which applies to all application code,
DCE implementations provide a mechanism to make system and library calls thread-safe.
This may be implemented either by providing a set of wrappers for unsafe calls or by
providing reentrant libraries and a nonblocking kernel threads implementation.
Applications must always be built using either the appropriate wrapped calls or linked to
the appropriate reentrant libraries.
DCE implementations provide, at the least, via wrappers or some other mechanism, the
set of thread-safe calls shown in Table 2-1.
Applications should not assume that a call to any routine not on this list is necessarily
thread-safe. Whether other routines are safe to call from a DCE applications depends on
the following factors:
• Application code that is single threaded (that has not explicitly created any
application threads via calls to the pthread API) need not concern itself about
reentrancy of routines not on this list, since all library and system calls made by RPC
created threads are included in this list. However, such application code must still
take care that no calls it makes will block the entire process.
• Application code that is multithreaded must exercise caution when making any call
not on this list. Non-reentrant library calls may be wrapped by the application using
pthread_lock_global_np( ), although this practice is discouraged since this call is
not portable. The global lock can be used only in limited circumstances; the
approach will work only if all threads in an application follow the same rule. Failure
to observe these restrictions can lead to deadlocks. Note also that this approach will
not work with any call that could block the whole process, for example by making a
blocking I/O call.
124246 Tandem Computers Incorporated 2−5