HOME
| OPENMP API Specification: Version 5.1 November 2020

2.12.6  Task Scheduling

Whenever a thread reaches a task scheduling point, the implementation may cause it to perform a task switch, beginning or resuming execution of a different task bound to the current team. Task scheduling points are implied at the following locations:

When a thread encounters a task scheduling point it may do one of the following, subject to the Task Scheduling Constraints (below):

If more than one of the above choices is available, which one is chosen is unspecified.

Task Scheduling Constraints are as follows:

1.
Scheduling of new tied tasks is constrained by the set of task regions that are currently tied to the thread and that are not suspended in a barrier region. If this set is empty, any new tied task may be scheduled. Otherwise, a new tied task may be scheduled only if it is a descendant task of every task in the set.
2.
A dependent task shall not start its execution until its task dependences are fulfilled.
3.
A task shall not be scheduled while any task with which it is mutually exclusive has been scheduled but has not yet completed.
4.
When an explicit task is generated by a construct that contains an if clause for which the expression evaluated to false, and the previous constraints are already met, the task is executed immediately after generation of the task.

A program that relies on any other assumption about task scheduling is non-conforming.

SVG-Viewer needed.

Note – Task scheduling points dynamically divide task regions into parts. Each part is executed uninterrupted from start to end. Different parts of the same task region are executed in the order in which they are encountered. In the absence of task synchronization constructs, the order in which a thread executes parts of different schedulable tasks is unspecified.

A program must behave correctly and consistently with all conceivable scheduling sequences that are compatible with the rules above.

For example, if threadprivate storage is accessed (explicitly in the source code or implicitly in calls to library routines) in one part of a task region, its value cannot be assumed to be preserved into the next part of the same task region if another schedulable task exists that modifies it.

As another example, if a lock acquire and release happen in different parts of a task region, no attempt should be made to acquire the same lock in any part of another task that the executing thread may schedule. Otherwise, a deadlock is possible. A similar situation can occur when a critical region spans multiple parts of a task and another schedulable task contains a critical region with the same name.

The use of threadprivate variables and the use of locks or critical sections in an explicit task with an if clause must take into account that when the if clause evaluates to false, the task is executed immediately, without regard to Task Scheduling Constraint 2.

SVG-Viewer needed.

Execution Model Events The task-schedule event occurs in a thread when the thread switches tasks at a task scheduling point; no event occurs when switching to or from a merged task.

Tool Callbacks A thread dispatches a registered ompt_callback_task_schedule callback for each occurrence of a task-schedule event in the context of the task that begins or resumes. This callback has the type signature ompt_callback_task_schedule_t. The argument prior_task_status is used to indicate the cause for suspending the prior task. This cause may be the completion of the prior task region, the encountering of a taskyield construct, or the encountering of an active cancellation point.

Cross References