![](https://csdnimg.cn/release/download_crawler_static/3621567/bg14.jpg)
12 OpenMP API • Version 3.1 July 2011
1.3 Execution Model
The OpenMP API uses the fork-join model of parallel execution. Multiple threads of
execution perform tasks defined implicitly or explicitly by OpenMP directives. The
OpenMP API 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 executes correctly as a parallel
program but not as a sequential program, or that produces different results when
executed as a parallel program compared to when it is executed as a sequential program.
Furthermore, using different numbers of threads 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.
An OpenMP program begins as a single thread of execution, called the initial thread.
The initial thread executes sequentially, as if enclosed in an implicit task region, called
the initial task region, that is defined by an implicit inactive parallel region
surrounding the whole program.
When any thread encounters a parallel construct, the thread creates a team of itself
and zero or more additional threads and becomes the master of the new team. A set of
implicit tasks, one per thread, is generated. The code for each task is defined by the code
inside the parallel construct. Each task is assigned to a different thread in the team
and becomes tied; that is, it is always executed by the thread to which it is initially
assigned. The task region of the task being executed by the encountering thread is
suspended, and each member of the new team executes its implicit task. There is an
implicit barrier at the end of the parallel construct. Only the master thread resumes
execution beyond the end of the parallel construct, resuming the task region that
was suspended upon encountering the parallel construct. Any number of
parallel constructs can be specified in a single program.
parallel regions may be arbitrarily nested inside each other. If nested parallelism is
disabled, or is not supported by the OpenMP implementation, then the new team that is
created by a thread encountering a parallel construct inside a parallel region
will consist only of the encountering thread. However, if nested parallelism is supported
and enabled, then the new team can consist of more than one thread.
When any team encounters a worksharing construct, the work inside the construct is
divided among the members of the team, and executed cooperatively instead of being
executed by every thread. There is a default barrier at the end of each worksharing
construct unless the nowait clause is present. Redundant execution of code by every
thread in the team resumes after the end of the worksharing construct.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38