Execution Model
OpenMP uses the fork-join model of parallel execution. Although this fork-join
model can be useful for solving a variety of problems, it is somewhat tailored for
large array-based applications. OpenMP is intended to support programs that will
execute correctly both as parallel programs (multiple threads of execution and a full
OpenMP support library) and as sequential programs (directives ignored and a
simple OpenMP stubs library). However, it is possible and permitted to develop a
program that does not behave correctly when executed sequentially. Furthermore,
different degrees of parallelism may result in different numeric results because of
changes in the association of numeric operations. For example, a serial addition
reduction may have a different pattern of addition associations than a parallel
reduction. These different associations may change the results of floating-point
addition.
A program written with the OpenMP C/C++ API begins execution as a single
thread of execution called the master thread. The master thread executes in a serial
region until the first parallel construct is encountered. In the OpenMP C/C++ API,
the parallel directive constitutes a parallel construct. When a parallel construct is
encountered, the master thread creates a team of threads, and the master becomes
master of the team. Each thread in the team executes the statements in the dynamic
extent of a parallel region, except for the work-sharing constructs. Work-sharing
constructs must be encountered by all threads in the team in the same order, and the
statements within the associated structured block are executed by one or more of the
threads. The barrier implied at the end of a work-sharing construct without a
nowait clause is executed by all threads in the team.
If a thread modifies a shared object, it affects not only its own execution
environment, but also those of the other threads in the program. The modification is
guaranteed to be complete, from the point of view of one of the other threads, at the
next sequence point (as defined in the base language) only if the object is declared to
be volatile. Otherwise, the modification is guaranteed to be complete after first the
modifying thread, and then (or concurrently) the other threads, encounter a flush
directive that specifies the object (either implicitly or explicitly). Note that when the
flush directives that are implied by other OpenMP directives are not sufficient to
ensure the desired ordering of side effects, it is the programmer's responsibility to
supply additional, explicit flush directives.
Upon completion of the parallel construct, the threads in the team synchronize at an
implicit barrier, and only the master thread continues execution. Any number of
parallel constructs can be specified in a single program. As a result, a program may
fork and join many times during execution.
The OpenMP C/C++ API allows programmers to use directives in functions called
from within parallel constructs. Directives that do not appear in the lexical extent of
a parallel construct but may lie in the dynamic extent are called orphaned directives.
Orphaned directives give programmers the ability to execute major portions of their
program in parallel with only minimal changes to the sequential program. With this
functionality, users can code parallel constructs at the top levels of the program call
tree and use directives to control execution in any of the called functions.
Unsynchronized calls to C and C++ output functions that write to the same file may
result in output in which data written by different threads appears in
nondeterministic order. Similarly, unsynchronized calls to input functions that read
from the same file may read data in nondeterministic order. Unsynchronized use of
I/O, such that each thread accesses a different file, produces the same results as
serial execution of the I/O functions.
Compliance
An implementation of the OpenMP C/C++ API is OpenMP-compliant if it recognizes
and preserves the semantics of all the elements of this specification, as laid out in
Chapters 1, 2, 3, 4, and Appendix C. Appendices A, B, D, E, and F are for information
purposes only and are not part of the specification. Implementations that include
only a subset of the API are not OpenMP-compliant.
The OpenMP C and C++ API is an extension to the base language that is supported
by an implementation. If the base language does not support a language construct or
extension that appears in this document, the OpenMP implementation is not
required to support it.
All standard C and C++ library functions and built-in functions (that is, functions of
which the compiler has specific knowledge) must be thread-safe. Unsynchronized
use of thread–safe functions by different threads inside a parallel region does not
produce undefined behavior. However, the behavior might not be the same as in a
serial region. (A random number generation function is an example.)
The OpenMP C/C++ API specifies that certain behavior is implementation-defined. A
conforming OpenMP implementation is required to define and document its
behavior in these cases. See Appendix E, page 97, for a list of implementationdefined
behaviors.
OpenMP uses the fork-join model of parallel execution. Although this fork-join
model can be useful for solving a variety of problems, it is somewhat tailored for
large array-based applications. OpenMP is intended to support programs that will
execute correctly both as parallel programs (multiple threads of execution and a full
OpenMP support library) and as sequential programs (directives ignored and a
simple OpenMP stubs library). However, it is possible and permitted to develop a
program that does not behave correctly when executed sequentially. Furthermore,
different degrees of parallelism may result in different numeric results because of
changes in the association of numeric operations. For example, a serial addition
reduction may have a different pattern of addition associations than a parallel
reduction. These different associations may change the results of floating-point
addition.
A program written with the OpenMP C/C++ API begins execution as a single
thread of execution called the master thread. The master thread executes in a serial
region until the first parallel construct is encountered. In the OpenMP C/C++ API,
the parallel directive constitutes a parallel construct. When a parallel construct is
encountered, the master thread creates a team of threads, and the master becomes
master of the team. Each thread in the team executes the statements in the dynamic
extent of a parallel region, except for the work-sharing constructs. Work-sharing
constructs must be encountered by all threads in the team in the same order, and the
statements within the associated structured block are executed by one or more of the
threads. The barrier implied at the end of a work-sharing construct without a
nowait clause is executed by all threads in the team.
If a thread modifies a shared object, it affects not only its own execution
environment, but also those of the other threads in the program. The modification is
guaranteed to be complete, from the point of view of one of the other threads, at the
next sequence point (as defined in the base language) only if the object is declared to
be volatile. Otherwise, the modification is guaranteed to be complete after first the
modifying thread, and then (or concurrently) the other threads, encounter a flush
directive that specifies the object (either implicitly or explicitly). Note that when the
flush directives that are implied by other OpenMP directives are not sufficient to
ensure the desired ordering of side effects, it is the programmer's responsibility to
supply additional, explicit flush directives.
Upon completion of the parallel construct, the threads in the team synchronize at an
implicit barrier, and only the master thread continues execution. Any number of
parallel constructs can be specified in a single program. As a result, a program may
fork and join many times during execution.
The OpenMP C/C++ API allows programmers to use directives in functions called
from within parallel constructs. Directives that do not appear in the lexical extent of
a parallel construct but may lie in the dynamic extent are called orphaned directives.
Orphaned directives give programmers the ability to execute major portions of their
program in parallel with only minimal changes to the sequential program. With this
functionality, users can code parallel constructs at the top levels of the program call
tree and use directives to control execution in any of the called functions.
Unsynchronized calls to C and C++ output functions that write to the same file may
result in output in which data written by different threads appears in
nondeterministic order. Similarly, unsynchronized calls to input functions that read
from the same file may read data in nondeterministic order. Unsynchronized use of
I/O, such that each thread accesses a different file, produces the same results as
serial execution of the I/O functions.
Compliance
An implementation of the OpenMP C/C++ API is OpenMP-compliant if it recognizes
and preserves the semantics of all the elements of this specification, as laid out in
Chapters 1, 2, 3, 4, and Appendix C. Appendices A, B, D, E, and F are for information
purposes only and are not part of the specification. Implementations that include
only a subset of the API are not OpenMP-compliant.
The OpenMP C and C++ API is an extension to the base language that is supported
by an implementation. If the base language does not support a language construct or
extension that appears in this document, the OpenMP implementation is not
required to support it.
All standard C and C++ library functions and built-in functions (that is, functions of
which the compiler has specific knowledge) must be thread-safe. Unsynchronized
use of thread–safe functions by different threads inside a parallel region does not
produce undefined behavior. However, the behavior might not be the same as in a
serial region. (A random number generation function is an example.)
The OpenMP C/C++ API specifies that certain behavior is implementation-defined. A
conforming OpenMP implementation is required to define and document its
behavior in these cases. See Appendix E, page 97, for a list of implementationdefined
behaviors.
No comments:
Post a Comment