OSF DCE Application Development Guide--Introduction and Style Guide

OSF DCE Application Development Guide—Introduction and Style Guide
must be taken and released in the same strict order. Rules like this are in not enforced by
the thread programming mechanisms, and failure to follow them will not always result in
program failures. In fact, failure to obey these rules may not always be a programming
error: depending on the program, it is certainly possible that there is no possible
execution path where failure to follow a rule would result in an error (although this might
be difficult to establish a priori).
As a result, such rules have in some sense the flavor of policy recommendations: they are
a set of disciplines for avoiding certain classes of problems which threads programmers
can assume to exist, in general, even though they might not arise in specific cases.
Because of this, and because these rules may be unfamiliar to many programmers, it
seems wise to repeat them in summary form in this policy guide. Moreover, because
DCE client and server applications are implicitly multithreaded, even when the
application itself makes no thread related calls, it is also important to identify when
application code must be thread safe. These issues are covered in Section 2.2.
The remaining sections of this chapter cover a variety of specific policy and usage issues
relating to DCE threads. Thread handles and thread-private data are discussed in
Sections 2.3.1 and 2.3.2.
Cancels and signals introduce a number of specific semantic issues that applications
must be aware of when programming in a multithreaded environment. These are covered
in Sections 2.3.3 and 2.3.4 respectively. Finally, DCE introduces the concept of an RPC
thread. This is intended to extend the semantics of a local thread of execution across two
address spaces in the course of an RPC. However, the extension is not entirely
transparent, and applications need to be aware of the semantic peculiarities of RPC
threads. These are covered in Section 2.4.
2.1 Thread Use Policy
Thread use policy questions arise in the following two ways:
• Server manager code is multithreaded by default, and applications can specify the
degree of multithreading.
• Client code can be made multithreaded by making threads API calls.
2.1.1 Choosing to Thread
The choice of multithreading is really a question of specific application design, and only
general guidelines can be supplied here. Application programmers need to be aware
that, depending on the threads implementation and the underlying hardware, concurrency
may be more apparent than real for many applications. If threads are being time-sliced
on a single processor, nonblocking activites will not go any faster because they are
multithreaded. In fact, given the extra overhead of a given threads implementation, they
may be slower. Even on a multiprocessor, with the DCE user-space threads
implementation, all threads in a single process contend for the same processor.
2− 2 Tandem Computers Incorporated 124246