HOME
| OPENMP API Specification: "Version 5.2 -- GIT rev 95b2e3a44"

10.1  parallel Construct

Name: parallel

Association: block

Category: executable

Properties: parallelism-generating, cancellable, thread-limiting, context-matching

Clauses

allocate, copyin, default, firstprivate, if, num_threads, private, proc_bind, reduction, shared

Binding

The binding thread set for a parallel region is the encountering thread. The encountering thread becomes the primary thread of the new team.

Semantics

When a thread encounters a parallel construct, a team of threads is created to execute the parallel region (see Section 10.1.1 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 primary 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 primary 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.

Within a parallel region, thread numbers uniquely identify each thread. Thread numbers are consecutive whole numbers ranging from zero for the primary 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 that the encountering thread is executing 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 Chapter 12).

An implicit barrier occurs at the end of a parallel region. After the end of a parallel region, only the primary thread of the team resumes execution of the enclosing task region.

If a thread in a team that is executing a parallel region encounters another parallel directive, it creates a new team, according to the rules in Section 10.1.1, and it becomes the primary thread 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 15.3.2 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.

Cross References