OpenMP-Examples/affinity/task_affinity.tex

\section{Task Affinity}
\label{sec: task_affinity}
\index{affinity!task affinity}
\index{affinity!affinity clause@\kcode{affinity} clause}
\index{clauses!affinity@\kcode{affinity}}
\index{affinity clause@\kcode{affinity} clause}

The next example illustrates the use of the \kcode{affinity}
clause with a \kcode{task} construct.
The variables in the \kcode{affinity} clause provide a
hint to the runtime that the task should execute
``close'' to the physical storage location of the variables. For example,
on a two-socket platform with a local memory component
close to each processor socket, the runtime will attempt to
schedule the task execution on the socket where the storage is located.

Because the C/C++ code employs a pointer, an array section is used in
the \kcode{affinity} clause.
Fortran code can use an array reference to specify the storage, as
shown here.

Note, in the second task of the C/C++ code the \ucode{B} pointer is declared
shared.  Otherwise, by default, it would be firstprivate since it is a local
variable, and would probably be saved for the second task before being assigned
a storage address by the first task.  Also, one might think it reasonable to use
the \kcode{affinity} clause \kcode{affinity(\ucode{B[:N]})} on the second \kcode{task} construct.
However, the storage behind \ucode{B} is created in the first task, and the 
array section reference may not be valid when the second task is generated.
The use of the \ucode{A} array is sufficient for this case, because one
would expect the storage for \ucode{A} and \ucode{B} would be physically ``close''
(as provided by the hint in the first task).

\cexample[5.0]{affinity}{6}

\ffreeexample[5.0]{affinity}{6}