Task Scheduling

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

[next] [prev] [prev-tail] [tail] [up]

12.9 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 diﬀerent task bound to the current team. Task scheduling points are implied at the following locations:

during the generation of an explicit task;
the point immediately following the generation of an explicit task;
after the point of completion of the structured block associated with a task;
in a taskyield region;
in a taskwait region;
at the end of a taskgroup region;
in an implicit barrier region;
in an explicit barrier region;
during the generation of a target region;
the point immediately following the generation of a target region;
at the beginning and end of a target data region;
in a target update region;
in a target enter data region;
in a target exit data region;
in the omp_target_memcpy routine;
in the omp_target_memcpy_async routine;
in the omp_target_memcpy_rect routine; and
in the omp_target_memcpy_rect_async routine.

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

begin execution of a tied task bound to the current team;
resume any suspended task region, bound to the current team, to which it is tied;
begin execution of an untied task bound to the current team; or
resume any suspended untied task region bound to the current team.

If more than one of the above choices is available, which one is chosen is unspeciﬁed.

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 descendent task of every task in the set.
2.: A dependent task shall not start its execution until its task dependences are fulﬁlled.
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.

Task scheduling points dynamically divide task regions into parts. Each part is executed uninterrupted from start to end. Diﬀerent 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 diﬀerent schedulable tasks is unspeciﬁed.

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 modiﬁes it.

As another example, if a lock acquire and release happen in diﬀerent 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.

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

ompt_callback_task_schedule_t, see Section 19.5.2.10

[next] [prev] [prev-tail] [front] [up]