DCE Threads
In a traditional computer program, there is only one thread of control. Execution of the program proceeds sequentially, and at any given time, there is only one point in the program that is currently executing. It is sometimes useful, however, to write a program that contains multiple threads of control. For example, some programs lend themselves to being structured as multiple flows of control, some programs show better performance when they are multithreaded, and multiple threads can be mapped to multiple processors when they are available.
A distributed computing environment based on the client/server model and remote procedure call can make good use of the capability for multiple threads of control. For example, when a client makes an RPC call, it blocks until a response is returned from the server. If there are multiple threads of control in the client, then work can continue in another thread while the thread waiting for the RPC response is blocked. On the server side, this same situation applies, since a server may itself issue an RPC. In addition, servers often handle the requests of multiple clients. It is sometimes easier to write a well-structured program when each request can be handled by a separate thread of control. Often servers manage information, requiring input/output operations to a storage device. While one server thread is waiting for its input or output operation to finish, another server thread can continue working, improving overall performance.
Using multiple threads puts new requirements on programmers: they must manage the threads, synchronize threads' access to global resources, and make choices about thread scheduling and priorities. A threads implementation must provide facilities for programmers to perform these tasks.
Threads can be provided by a programming language, an operating system kernel, or a user-space library. DCE Threads is provided as a user-space library; this has implications for its interaction with other software on the system, such as an operating system that delivers signals to or blocks a whole process, rather than just a thread, and pre-existing library calls that were not originally written for a multithreaded environment.
The following subsections give an overview of the DCE Threads technology component. They describe the different kinds of functions provided by the technology, and how DCE Threads is seen from the end user's, programmer's, and administrator's perspective, focusing particularly on programming with DCE Threads, since the application programmer is the main consumer of this technology.
More:
Additional Information on DCE Threads