SummaryThe parallel construct creates a team of OpenMP threads that execute the region.
Syntax
The syntax of the parallel construct is as follows:
#pragma omp parallel [clause[ [,] clause] ... ] new-line
structured-block
where clause is one of the following:
if([parallel :] scalar-expression)
num_threads(integer-expression)
default(shared | none)
private(list)
firstprivate(list)
shared(list)
copyin(list)
reduction([reduction-modifier ,] reduction-identifier : list)
proc_bind(master | close | spread)
allocate([allocator :] list)
The syntax of the parallel construct is as follows:
!$omp parallel [clause[ [,] clause] ... ]
structured-block
!$omp end parallel
where clause is one of the following:
if([parallel :] scalar-logical-expression)
num_threads(scalar-integer-expression)
default(private | firstprivate | shared | none)
private(list)
firstprivate(list)
shared(list)
copyin(list)
reduction([reduction-modifier ,] reduction-identifier : list)
proc_bind(master | close | spread)
allocate([allocator :] list)
BindingThe binding thread set for a parallel region is the encountering thread. The encountering thread becomes the master thread of the new team.
DescriptionWhen a thread encounters a parallel construct, a team of threads is created to execute the parallel region (see Section 2.6.1 on page 224 for more information about how the number of threads in the team is determined, including the evaluation of the if and num_threads clauses). The thread that encountered the parallel construct becomes the master thread of the new team, with a thread number of zero for the duration of the new parallel region. All threads in the new team, including the master thread, execute the region. Once the team is created, the number of threads in the team remains constant for the duration of that parallel region. The optional proc_bind clause, described in Section 2.6.2 on page 227, specifies the mapping of OpenMP threads to places within the current place partition, that is, within the places listed in the place-partition-var ICV for the implicit task of the encountering thread.
Within a parallel region, thread numbers uniquely identify each thread. Thread numbers are consecutive whole numbers ranging from zero for the master thread up to one less than the number of threads in the team. A thread may obtain its own thread number by a call to the omp_get_thread_num library routine.
A set of implicit tasks, equal in number to the number of threads in the team, is generated by the encountering thread. The structured block of the parallel construct determines the code that will be executed in each implicit task. Each task is assigned to a different thread in the team and becomes tied. The task region of the task being executed by the encountering thread is suspended and each thread in the team executes its implicit task. Each thread can execute a path of statements that is different from that of the other threads.
The implementation may cause any thread to suspend execution of its implicit task at a task scheduling point, and to switch to execution of any explicit task generated by any of the threads in the team, before eventually resuming execution of the implicit task (for more details see Section 2.10 on page 384).
There is an implied barrier at the end of a parallel region. After the end of a parallel region, only the master thread of the team resumes execution of the enclosing task region.
If a thread in a team executing a parallel region encounters another parallel directive, it creates a new team, according to the rules in Section 2.6.1 on page 224, and it becomes the master of that new team.
If execution of a thread terminates while inside a parallel region, execution of all threads in all teams terminates. The order of termination of threads is unspecified. All work done by a team prior to any barrier that the team has passed in the program is guaranteed to be complete. The amount of work done by each thread after the last barrier that it passed and before it terminates is unspecified.
Execution Model Events The parallel-begin event occurs in a thread that encounters a parallel construct before any implicit task is created for the corresponding parallel region.
Upon creation of each implicit task, an implicit-task-begin event occurs in the thread that executes the implicit task after the implicit task is fully initialized but before the thread begins to execute the structured block of the parallel construct.
If the parallel region creates a native thread, a native-thread-begin event occurs as the first event in the context of the new thread prior to the implicit-task-begin event.
Events associated with implicit barriers occur at the end of a parallel region. Section 2.17.3 describes events associated with implicit barriers.
When a thread finishes an implicit task, an implicit-task-end event occurs in the thread after events associated with implicit barrier synchronization in the implicit task.
The parallel-end event occurs in the thread that encounters the parallel construct after the thread executes its implicit-task-end event but before the thread resumes execution of the encountering task.
If a native thread is destroyed at the end of a parallel region, a native thread-end event occurs in the thread as the last event prior to destruction of the thread.
Tool Callbacks A thread dispatches a registered ompt_callback_parallel_begin callback for each occurrence of a parallel-begin event in that thread. The callback occurs in the task that encounters the parallel construct. This callback has the type signature ompt_callback_parallel_begin_t. In the dispatched callback, (flags & ompt_parallel_team) evaluates to true.
A thread dispatches a registered ompt_callback_implicit_task callback with ompt_scope_begin as its endpoint argument for each occurrence of an implicit-task-begin event in that thread. Similarly, a thread dispatches a registered ompt_callback_implicit_task callback with ompt_scope_end as its endpoint argument for each occurrence of an implicit-task-end event in that thread. The callbacks occur in the context of the implicit task and have type signature ompt_callback_implicit_task_t. In the dispatched callback, (flags & ompt_task_implicit) evaluates to true.
A thread dispatches a registered ompt_callback_parallel_end callback for each occurrence of a parallel-end event in that thread. The callback occurs in the task that encounters the parallel construct. This callback has the type signature ompt_callback_parallel_end_t.
A thread dispatches a registered ompt_callback_thread_begin callback for the native-thread-begin event in that thread. The callback occurs in the context of the thread. The callback has type signature ompt_callback_thread_begin_t.
A thread dispatches a registered ompt_callback_thread_end callback for the native-thread-end event in that thread. The callback occurs in the context of the thread. The callback has type signature ompt_callback_thread_end_t.
RestrictionsRestrictions to the parallel construct are as follows:
∙ A throw executed inside a parallel region must cause execution to resume within the same parallel region, and the same thread that threw the exception must catch it.