3. Language Directives¶

This chapter describes the OmpSs-2 language, this is, all the necessary elements to understand how an OmpSs-2 application executes and/or behaves in a parallel architecture. OmpSs-2 provides a simple path for users already familiarized with the OpenMP programming model to easily write (or port) their programs to OmpSs-2.

This description is completely guided by the list of OmpSs-2 directives. In each of the following sections we will find a short description of the directive, its specific syntax, the list of clauses (including the list of valid parameters for each clause and a short description for them). In addition, each section finalizes with a simple example showing how this directive can be used in a valid OmpSs-2 program.

As is the case of OpenMP in C and C++, OmpSs-2 directives are specified using the #pragma mechanism (provided by the base language) and in Fortran they are specified using special comments that are identified by a unique sentinel. The sentinel used in OmpSs-2 is oss. Compilers will typically ignore OmpSs-2 directives if support is disabled or not provided.

C/C++ format:

#pragma oss directive-name [clause[ [,] clause] ... ] new-line

Fortran format:

sentinel directive-name [clause[ [,] clause]...]

Where depend on Fortran fixed/free form:

The sentinels for fixed form can be: !$oss, c$oss or *$oss. Sentinels must start in column 1. Continued directive line must have a character other than a space or a zero in column 6.
The sentinel for free form must be !$oss. This sentinel can appear in any column as long as is not preceeded by any character different than space. Continued directive line must have an ampersand (&).

3.1. Task construct¶

The programmer can specify a task using the task construct. This construct can appear inside any code block of the program, which will mark the following statement as a task.

The syntax of the task construct is the following:

#pragma oss task [clauses]
structured-block

The valid clauses for the task construct are:

private(<list>)

firstprivate(<list>)

shared(<list>)

depend(<type>: <memory-reference-list>)

<depend-type>(<memory-reference-list>)

reduction(<operator>:<memory-reference-list>)

priority(<expression>)

cost(<expression>)

if(<scalar-expression>)

final(<scalar-expression>)

wait

onready(<statement>)

label(<string>)

The private, firstprivate and shared clauses allow to specify the data sharing attribute of the variables referenced in the construct. A description of these clauses can be found in Data sharing attributes section.

The depend clause allows to infer additional task scheduling restrictions from the parameters it defines. These restrictions are known as dependences. The syntax of the depend clause include a dependence type, followed by colon and its associated list items. The list of valid type of dependences are defined in section Dependence model in the previous chapter. In addition to this syntax, OmpSs-2 allows to specify this information using the type of dependence as the name of the clause. Then, the following code:

#pragma oss task depend(in: a,b,c) depend(out: d)

Is equivalent to this one:

#pragma oss task in(a,b,c) out(d)

The reduction clause allows to define the task as a participant of a reduction operation. The first occurrence of a participating task defines the begin of the scope for the reduction. The end of the scope is implicitly ended by a taskwait or a dependence over the memory-reference-item. More information about task reductions on OmpSs-2 at the following Master Thesis: https://upcommons.upc.edu/handle/2117/129246.

The priority clause indicates a priority hint for the task. Greater numbers indicate higher priority, and lower numbers indicate less priority. By default, tasks have priority 0. The expression of the priority is evaluated as a singed integer. This way, strictly positive priorities indicate higher priority than the default, and negative priorities indicate lower than default priority.

If the expression of the if clause evaluates to true, the execution of the new created task can be deferred, otherwise the current task must suspend its execution until the new created task has complete its execution.

If the expression of the final clause evaluates to true, the new created task will be a final task and all the task generating code encountered when executing its dynamic extent will also generate final tasks. In addition, when executing within a final task, all the encountered task generating codes will execute these tasks immediately after its creation as if they were simple routine calls. And finally, tasks created within a final task can use the data environment of its parent task.

Tasks with the wait clause will perform a taskwait-like operation immediately after exiting from the task code. Since it is performed outside the scope of the code of the task, this happens once the task has abandoned the stack. For this reason, its use is restricted to tasks that upon exiting do not have any subtask accessing its local variables. Otherwise, the regular taskwait shall be used instead.

The for clause (do in Fortran) marks the task as a worksharing task, which can be applied when the task body is a for-loop. This is explained in section Task For clause.

The onready clause allow defining an action in the form of a statement (e.g., a call to a function) that will be executed once the task becomes ready. This is explained in more detail in section Task Onready clause.

The label clause defines a string literal that can be used by any performance or debugger tool to identify the task with a more human-readable format. The string literal must be wrapped in double quotes. For instance, a task that initializes an array could be labeled as label("init array").

The following C code shows an example of creating tasks using the task construct:

float x = 0.0;
float y = 0.0;
float z = 0.0;

int main() {
  #pragma oss task
  do_computation(x);

  #pragma oss task
  {
    do_computation(y);
    do_computation(z);
  }
  #pragma oss taskwait

  return 0;
}

When the control flow reaches #pragma oss task construct, a new task instance is created. The execution order of the tasks is not guaranteed. Moreover, when the program reaches the #pragma oss taskwait the previously created tasks may not have been executed yet by the OmpSs-2 run-time system. After potentially being blocked in the taskwait construct for a while, it is guaranteed that both tasks have already deeply completed.

The task construct is extended to allow the annotation of function declarations or definitions in addition to structured-blocks. When a function is annotated with the task construct each invocation of that function becomes a task creation point. The following C code is an example of how task functions are used:

extern void do_computation(float a);

#pragma oss task
extern void do_computation_task(float a);

float x = 0.0;
int main() {
  do_computation_task(x); //this will create a task
  do_computation(x); //regular function call

  #pragma oss taskwait
}

The invocation of do_computation_task inside main function creates an instance of a task. Note that OmpSs-2 does not gaurantee that the task has been already executed after returning from the regular function call do_computation(x).

Note that only the execution of the function itself is part of the task not the evaluation of the task arguments. Another restriction is that the task is not allowed to have any return value, that is, the return must be void.

3.1.1. Task For clause¶

Important

Task worksharings, which were implemented by the task for clause, are no longer part of OmpSs-2.

3.1.2. Task Onready clause¶

The onready clause allows defining an action in the form of a statement (e.g., a call to a function) that will be executed once the task becomes ready. The run-time system will execute the statement only once, at any moment after the task satisfies all its data dependencies and before the task runs its body. The onready action cannot assume that is running within a task context; it should not reach any task scheduling point. Moreover, the action is recommended to be lightweight and should not perform blocking operations.

The onready action can register external events to the ready task to delay its execution until all the events are fulfilled. As an example, the callback could execute an asynchronous TAMPI operation, such as TAMPI_Iwait. Such a call would delay the task’s execution until the corresponding MPI communications are completed. In that way, the data dependencies allow tasks to define local dependencies with other tasks on the same process, whereas the onready clause allows defining remote dependencies with other processes. See Task external events for more information about the management of task external events.

The data sharing and dependency rules for the variables used in the onready action are the same that apply to the task body.

We show an example below where a task safely increases by two the value of a variable from the onready action and the task body:

void function(int *a)
{
  // This is the first increase because it's the onready action
  *a += 1;
}

int main()
{
  int a = 0;

  #pragma oss task inout(a) onready(function(&a))
  {
    // At this point, the onready action was already executed
    ++a;
  }

  #pragma oss taskwait

  fprintf(stdout, "a: %d\n", a); // Should print "a: 2"
}

Below there is an example where we asynchronously receive (through TAMPI services) and process remote data using a single task with an onready action:

void function(int *a, int rank)
{
  MPI_Request request;
  MPI_Irecv(a, 1, MPI_INT, src, 0, MPI_COMM_WORLD, &request);

  // Asynchronously delay the execution of the task until the communication
  // has completed. This service will register an external event if the
  // receive has not completed immediately
  TAMPI_Iwait(&request, MPI_STATUS_IGNORE);
}

int main()
{
  // Initialize MPI...

  int a = 0;
  int rank = ...;

  #pragma oss task inout(a) onready(function(&a, rank))
  {
    fprintf(stdout, "received data: %d\n", a);
    process(a);
  }

  #pragma oss taskwait

  // Finalize MPI...
}

Please note this is just an example of how onready can be used to delay the execution of a task by registering external events. Performing heavy operations like MPI_Irecv in an onready action is not recommended because the onready action does not run in the context of a task.

3.2. Taskwait construct¶

Apart from implicit synchronization (task data dependences), OmpSs-2 also offers a mechanism that allow users to synchronize task execution. The taskwait construct is an stand-alone directive (with no code block associated) and specifies a wait on the deep completion of all descendant tasks, including the non-direct children tasks.

The syntax of the taskwait construct is the following:

#pragma oss taskwait [clauses]

The valid clauses for the taskwait construct are the following:

on(list-of-variables): It specifies to wait only for the subset (not all of them) of descendant tasks that declared a dependency on any of the variables that appear on the list of variables.

The on clause allows to wait only on the tasks that produces some data in the same way as the inout clause. It suspends the current task until all previous tasks with any dependency on the expression are completed. The following example illustrates its use:

int compute1(void);
int compute2(void);

int main()
{
  int result1, result2;

  #pragma oss task out(result1)
  result1 = compute1();

  #pragma oss task out(result2)
  result2 = compute2();

  #pragma oss taskwait on(result1)
  printf("result1 = %d\n", result1);

  #pragma oss taskwait on(result2)
  printf("result2 = %d\n", result2);

  return 0;
}

3.3. Release directive¶

The release directive asserts that a task will no longer perform accesses that conflict with the contents of the associated depend clause. The contents of the depend clause must be a subset of that of the task construct that is no longer referenced in the rest of the lifetime of the current task and its future subtasks. The release directive has not associated structured block.

The syntax of the release directive is the following:

#pragma oss release [clauses]

The valid clauses for the release directive are:

depend(<type>: <memory-reference-list>)

<depend-type>(<memory-reference-list>)

The following C code shows an example of partial release of the task dependences using the release directive:

#define SIZE 4096

float x[SIZE];
float y[SIZE];

int main() {

  #pragma oss task depend(out:x,y)
  {
     for (int i=0; i<SIZE; i++) x[i] = 0.0;
     #pragma oss release depend(out:x)

     for (int i=0; i<SIZE; i++) y[i] = 0.0;
  }
}

Warning

At this moment, the run-time system only supports releasing a dependency of the same dependency type that was specified at the task depend clause.

3.4. Critical construct¶

The critical construct allows programmers to specify regions of code that will be executed in mutual exclusion. The associated region will be executed by a single thread at a time, other threads will wait at the beginning of the critical section until no thread is executing it.

The syntax of the critical construct is the following:

#pragma oss critical
structured-block

The syntax also allows named criticals with the following syntax:

#pragma oss critical(<name>)
structured-block

Named criticals prevent concurrency between threads with respect to all critical regions with the same name. Unnammed criticals prevent concurrency between threads with respect to all unnamed critical regions.

The critical construct has no related clauses. The beginning and ending of a critical section may be task scheduling points.

3.5. Assert directive¶

The assert is a declarative directive that checks whether any runtime configuration option is enabled or has a specific value. The directive expects a single string with comma-separated conditions. Each condition is composed of the option name, a comparison operator (==, !=, >, >=, < and <=), and the value to compare.

All conditions are checked before starting the program, and if any fails, the program aborts showing an error with the incorrect option. The configuration options are runtime-specific, so each runtime system may define its valid configuration options. Since this directive is declarative, it should be written in any part of the program’s source code files.

The syntax of the assert directive is:

#pragma oss assert("option1==40,option2<10,option3!=stringvalue")

int main() {
  // ...
}

Check the OmpSs-2 User Guide to see the runtime configuration options that can be asserted. For instance, we can assert that a program is running using the regions dependency system and that the thread stack size is greater than 4MB with the following code:

#pragma oss assert("version.dependencies==regions,misc.stack_size>4M")

int main() {
  // ...
}

3.6. Restrictions¶

The point of exit of a stuctured block cannot be a branch out of it. The following C code shows an example where any of the exit calls may lead to undefined behavior:

int main() {

  for (int i = 0; i < 10; i++) {
    if (i > 5) exit(1);

    #pragma oss task
    {
      // computation
      exit(1);
    }
  }
  #pragma oss taskwait
}

OmpSs-2 Spec

Navigation