![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
Revision/Update Information: This manual supersedes the Guide to DECthreads, December 1995.
Software Version: OpenVMS Alpha Version 7.1 OpenVMS VAX Version 7.1
Digital Equipment Corporation Maynard, Massachusetts
Digital Equipment Corporation makes no representations that the use of its products in the manner described in this publication will not infringe on existing or future patent rights, nor do the descriptions contained in this publication imply the granting of licenses to make, use, or sell equipment or software in accordance with the description.
Possession, use, or copying of the software described in this publication is authorized only pursuant to a valid written license from Digital or an authorized sublicensor.
Digital conducts its business in a manner that conserves the environment and protects the safety and health of its employees, customers, and the community.
© Digital Equipment Corporation 1996. All rights reserved.
The following are trademarks of Digital Equipment Corporation: Bookreader, DEC Ada, DEC Fortran, DECdirect, DECthreads, DECwindows, Digital, OpenVMS, OpenVMS Cluster, VAX, VAX Ada, VAX C, VAX DOCUMENT, VAX FORTRAN, VAX MACRO, VAXcluster, VMS, and the DIGITAL logo.
The following are third-party trademarks:
IEEE is a registered trademark of the Institute of Electrical and Electronics Engineers, Inc.
Microsoft, MS, MS--DOS, Win32, and Windows 95 are registered trademarks, and Windows NT is a trademark of Microsoft Corporation.
POSIX is a registered trademark of the IEEE.
UNIX is a registered trademark in the United States and other countries licensed exclusively through X/Open Company, Ltd.
All other trademarks and registered trademarks are the property of their respective holders.
ZK6493
The OpenVMS documentation set is available on CD-ROM.
This guide describes DECthreads, Digital's Multithreading Run-Time Library. In addition to introducing DECthreads components for building multithreaded applications and libraries to be called from other single-threaded or multithreaded programs, this guide reviews the key principles of multithreaded programming as reflected in the IEEE POSIX 1003.1c-1995 standard.
This guide also presents the concepts behind thread-safe and multithreaded processing environments and provides guidelines for using DECthreads to implement them on various Digital platforms. Finally, this guide describes in detail each routine in the two recommended DECthreads interfaces:
The interface you select depends upon your goals and the anticipated environment for your application.
This guide is for system and application programmers who use DECthreads to create multithreaded applications or to create thread-safe code libraries that can be called from single-threaded or multithreaded applications.
This guide consists of the following:
Part 4 - Appendixes
Glossary
See your system's documentation set for more information on that system. DECthreads is available on the following platforms:
For a complete list and description of the books in the OpenVMS documentation set, see the Overview of OpenVMS Documentation.
For additional information on the Open Systems Software Group (OSSG) products and services, access the Digital OpenVMS World Wide Web site. Use the following URL:
http://www.openvms.digital.com
Digital welcomes your comments on this guide.
Print or edit the online form SYS$HELP:OPENVMSDOC_COMMENTS.TXT and send us your comments by:
| Internet | writer@dceidl.enet.dec.com |
| Fax | 603 881-0120, Attention: Core Technology Group, ZKO2-3/Q18 |
|
Core Technology Group, ZKO2-3/Q18
110 Spit Brook Rd. Nashua, NH 03062-2698 |
Use the following table to order additional documentation or information. If you need help deciding which documentation best meets your needs, call 800-DIGITAL (800-344-4825).
The name of the OpenVMS AXP operating system has been changed to the OpenVMS Alpha operating system. Any references to OpenVMS AXP or AXP are synonymous with OpenVMS Alpha or Alpha.
VMScluster systems are now referred to as OpenVMS Cluster systems. Unless otherwise specified, references to OpenVMS Clusters or clusters in this document are synonymous with VMSclusters.
The following conventions are also used in this manual:
| Ctrl/ x | A sequence such as Ctrl/ x indicates that you must hold down the key labeled Ctrl while you press another key or a pointing device button. |
|
PF1
x or
GOLD x |
A sequence such as PF1
x or GOLD
x indicates that you must first press and release the key
labeled PF1 or GOLD and then press and release another key or a
pointing device button.
GOLD key sequences can also have a slash (/), dash (--), or underscore (_) as a delimiter in EVE commands. |
| [Return] | In examples, a key name enclosed in a box indicates that you press a key on the keyboard. (In text, a key name is not enclosed in a box.) |
| ... |
Horizontal ellipsis points in examples indicate one of the following
possibilities:
|
|
.
. . |
Vertical ellipsis points indicate the omission of items from a code example or command format; the items are omitted because they are not important to the topic being discussed. |
| ( ) | In command format descriptions, parentheses indicate that, if you choose more than one option, you must enclose the choices in parentheses. |
| [ ] | In command format descriptions, brackets indicate optional elements. You can choose one, none, or all of the options. (Brackets are not optional, however, in the syntax of a directory name in an OpenVMS file specification or in the syntax of a substring specification in an assignment statement.) |
| { } | In command format descriptions, braces indicate a required choice of options; you must choose one of the options listed. |
| text style |
This text style represents the introduction of a new term or the name
of an argument, an attribute, or a reason.
This style is also used to show user input in Bookreader versions of the manual. |
| italic text | Italic text indicates important information, complete titles of manuals, or variables. Variables include information that varies in system output (Internal error number), in command lines (/PRODUCER= name), and in command parameters in text (where device-name contains up to five alphanumeric characters). |
| UPPERCASE TEXT | Uppercase text indicates a command, the name of a routine, the name of a file, or the abbreviation for a system privilege. |
| Monospace type |
Monospace type indicates code examples and interactive screen displays.
In the C programming language, monospace type in text identifies the following elements: keywords, the names of independently compiled external functions and files, syntax summaries, and references to variables or identifiers introduced in an example. |
| - | A hyphen at the end of a command format description, command line, or code line indicates that the command or statement continues on the following line. |
| numbers | All numbers in text are assumed to be decimal unless otherwise noted. Nondecimal radixes---binary, octal, or hexadecimal---are explicitly indicated. |
This chapter introduces the concepts of threads and multithreaded programming. It describes four functional models that can be a basis for constructing multithreaded applications. The concepts and techniques introduced here are described in more detail in Chapter 2 and in this guide's platform-specific appendixes.
This chapter's last section introduces the components of the DECthreads
package, in particular the pthread and
tis interfaces, and how those components support
building multithreaded applications and thread-safe libraries.
1.1 Advantages of Using Threads
Multithreaded programming means organizing and coding a program so that instances of its routines, called threads, can execute concurrently in the same process. You use threads to improve a program's performance---that is, its throughput, computational speed, responsiveness, or some combination.
Using threads can improve a program's performance on uniprocessor systems by permitting the overlap of input, output, or other slow operations with computational operations. Threads are useful in driving slow devices such as disks, networks, terminals, and printers. A multithreaded program can perform other useful work while waiting for the device to produce its next event, such as the completion of a disk transfer or the receipt of a packet from the network.
Using threads can also be advantageous when constructing an application's user interface. Consider the typical arrangement of a window system. Each time the user invokes an action (for example, by clicking on a mouse button), the program can use a separate thread to implement the action. If the user invokes multiple actions, multiple threads can perform the actions in parallel.
Using threads is especially advantageous when building a distributed system. These systems frequently contain a shared network server, where the server services requests from multiple clients. Using multiple threads allows the server to handle clients' requests in parallel, instead of artificially serializing them or creating (at great expense) one server process per client.
A program with multiple threads can be especially suited to run on a
multiprocessor system, where threads run concurrently on separate
processors. Threads created using the DECthreads library are capable of
utilizing multiprocessors, if the operating system on that platform
supports parallelism within a process.
1.2 Overview of Threads
A thread is a single, sequential flow of control within a process. Within each thread there is a single point of execution. Most traditional programs execute as a process with a single thread. Figure 1-1 and Figure 1-2 show the differences between a single-threaded process and a multithreaded process.
Figure 1-1 Single-Threaded Process
In Figure 1-2, notice that multiple threads share heap storage, static storage, and code but that each thread has its own register set and stack.
Using DECthreads, Digital's multithreading run-time library, a programmer can create several threads within a process. The process's threads execute concurrently. Within a multithreaded program there are at any time multiple points of execution.
Threads execute within (and share) a single address space; therefore, a process's threads can read and write the same memory locations. When the threads access the same memory locations, your program must use synchronization elements, such as mutexes and condition variables, to ensure that the shared memory is accessed correctly. DECthreads provides routines that allow you to use these and other synchronization objects. Section 2.4 describes the synchronization objects that DECthreads offers as well as the operations your program can perform on them.
Figure 1-2 Multithreaded Process
You should design and code a multithreaded program with the assumption that its threads execute simultaneously. That is, your program cannot make assumptions about the relative start or finish times of its threads or the sequence in which they execute. These are governed by the DECthreads thread scheduler, part of the run-time environment that DECthreads establishes before your program begins running. Nevertheless, your program can influence how DECthreads schedules its threads, by setting each thread's scheduling policy and scheduling priority. (Section 2.3.6 describes how thread scheduling works.)
Each thread has its own thread identifier, which distinguishes it from all other threads in the process. In addition to the thread's scheduling policy and scheduling priority, each thread is associated with any thread-specific instances of thread-common data objects and with thread-specific system resources to support a flow of control.
A thread changes its state over the course of its execution. A thread is in one of the following states:
Figure 1-3 shows the transitions between states for a typical thread implementation.
Figure 1-3 Thread State Transitions
Note
Building your multithreaded program must produce executable code that is reentrant. Therefore, be sure that your compiler generates reentrant code before you design or code your multithreaded program. By default, Digital's C, C++, Ada, Pascal, and BLISS compilers generate reentrant code.If you cannot build your program so that its executable code is reentrant, it might be impossible to keep the program's threads from interfering with each other. See Section 3.8.1 for more information about thread-reentrant libraries.
In general, when using threads, be aware of language-based programming practices that are inherently not thread safe. ("Thread safety" is explained in Section 3.8.2.) You must address these factors when writing multithreaded applications and thread-safe libraries. For example, Fortran language routines typically rely heavily upon static storage, which can prevent those routines from being thread safe.
The following sections describe four functional models of processing information that are especially well suited for implementation in multithreaded programs:
In a boss/worker model, one thread functions as the "boss" because it assigns tasks for "worker" threads to perform. Each worker performs a distinct task until it has finished, at which point it notifies the boss that it is ready to receive another task. Alternatively, the boss polls workers periodically to see whether any is ready to receive another task.
A variation of the boss/worker model is the work queue model. The boss places tasks in a queue, and workers check the queue and take tasks to perform.
An example of the work queue model in an office environment is a
secretarial typing pool. The office manager boss puts documents to be
typed in a basket, and worker typists take documents from the basket to
work on.
1.4.2 Work Crew Model
In the work crew model, multiple threads work together on a single task. The task is divided into pieces that are performed in parallel, and each thread performs one piece.
An example of a work crew is a group of people cleaning a building. Each person cleans certain rooms or performs certain types of work (washing floors, polishing furniture, and so forth), and each works independently.
In a multithreaded program that reflects the work crew model, each thread executes a task that can be performed in parallel. Figure 1-4 shows a task performed by three threads in a work crew model.
Figure 1-4 Work Crew Model of Thread Operation
In the pipelining model, a task is divided into steps. The steps must be performed in sequence to produce a single instance of the desired result, and the work done in each step (except for the first and last) is based on the previous step and is a prerequisite for the work in the next step. However, the goal is to produce multiple instances of the desired result, and the steps are designed to operate in parallel: while one step is performed on one instance of the result, the preceding step can be performed on the next instance of the result.
An example of the pipelining model is an automobile assembly line. Each step or stage in the assembly line is continually busy receiving the product of the previous stage's work, performing its assigned work, and passing the product along to the next stage.
In a multithreaded program that reflects the pipelining model, each thread executes a step in the task. Figure 1-5 shows a task performed by three threads in a pipelining model.
Figure 1-5 Pipelining Model of Thread Operation
If the task that your program performs is complex, you might find it
appropriate to organize it as a combination of the functional models
previously described. For example, a program could follow the
pipelining model, but with one or more steps performed by a set of
threads that follow a work crew model. In addition, threads could be
assigned to a work crew by taking a task from a work queue and deciding
(based on the task characteristics) which threads are needed for the
work crew.
1.5 Potential Issues for Multithreaded Programs
When you design and code a multithreaded program, you must accommodate or eliminate, as appropriate, each of the following issues:
As a package, DECthreads is a collection of shared code libraries and C language header files that declare entry points into those libraries. This guide's platform-specific appendixes describe these libraries in more detail and list all other libraries upon which the DECthreads libraries depend.
From the programmer's view, the DECthreads libraries offer interfaces. Each interface is a distinct set of routines that together provide a well-defined set of related data objects and operations.
This version of DECthreads supports two interfaces that are documented in this guide:
This release of DECthreads includes interface definitions for the C programming language only. However, all DECthreads routines are callable from languages other than C. Your application must provide its own declarations for DECthreads routines in a manner appropriate to its programming language. These definitions should be modeled after the declarations in the C language pthread.h header file.
For backward compatibility, this version of DECthreads also supports
other interfaces that are not documented in this guide. See
Section 1.6.3.
1.6.1 Multithreading pthread Interface
This version of DECthreads offers one documented interface for multithreading capability. The pthread interface routines implement the IEEE Standard 1003.1c-1995, Portable Operating System Interface (or POSIX) Application Program Interface, also known as POSIX.1c. (More specifically, this interface is an extension to the 1003.1 Portable Operating System Interface standard rather than an independent interface specification.)
6493P.HTM OSSG Documentation 22-NOV-1996 13:19:54.89
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.