mirror of
https://github.com/OpenMP/Examples.git
synced 2025-04-04 05:41:33 +01:00
68 lines
3.2 KiB
TeX
68 lines
3.2 KiB
TeX
%\pagebreak
|
|
\begin{fortranspecific}[4ex]
|
|
\section{Fortran \bcode{ASSOCIATE} Construct}
|
|
\label{sec:associate}
|
|
\index{ASSOCIATE construct, Fortran@\bcode{ASSOCIATE} construct, Fortran}
|
|
|
|
The following is an invalid example of specifying an associate name on a data-sharing attribute
|
|
clause. The constraint in the \docref{Data Sharing Attribute Rules} section in the OpenMP
|
|
4.0 API Specification states that an associate name preserves the association
|
|
with the selector established at the \bcode{ASSOCIATE} statement. The associate
|
|
name \ucode{b} is associated with the shared variable \ucode{a}. With the predetermined data-sharing
|
|
attribute rule, the associate name \ucode{b} is not allowed to be specified on the \kcode{private}
|
|
clause.
|
|
|
|
%\pagebreak
|
|
\fnexample[4.0]{associate}{1}
|
|
|
|
In next example, within the \kcode{parallel} construct, the association name \ucode{thread_id}
|
|
is associated with the private copy of \ucode{i}. The print statement should output the
|
|
unique thread number.
|
|
|
|
\fnexample[4.0]{associate}{2}
|
|
|
|
The following example illustrates the effect of specifying a selector name on a data-sharing
|
|
attribute clause. The associate name \ucode{u} is associated with \ucode{v} and the variable \ucode{v}
|
|
is specified on the \kcode{private} clause of the \kcode{parallel} construct.
|
|
The construct association is established prior to the \kcode{parallel} region.
|
|
The association between \ucode{u} and the original \ucode{v} is retained (see the \docref{Data Sharing
|
|
Attribute Rules} section in the OpenMP 4.0 API Specification). Inside the \kcode{parallel}
|
|
region, \ucode{v} has the value of -1 and \ucode{u} has the value of the original \ucode{v}.
|
|
|
|
\topmarker{Fortran}
|
|
\ffreenexample[4.0]{associate}{3}
|
|
|
|
%\topmarker{Fortran}
|
|
\label{sec:associate_target}
|
|
|
|
\bigskip
|
|
The following example illustrates mapping behavior for a Fortran
|
|
associate name and its selector for a \kcode{target} construct.
|
|
|
|
For the first 3 \kcode{target} constructs the associate name \ucode{a_aray} is
|
|
associated with the selector \ucode{aray}, an array.
|
|
For the \kcode{target} construct of code block TARGET 1 just the selector
|
|
\ucode{aray} is used and is implicitly mapped,
|
|
likewise for the associate name \ucode{a_aray} in the TARGET 2 block.
|
|
However, mapping an associate name and its selector is not valid for the same
|
|
\kcode{target} construct. Hence the TARGET 3 block is non-conforming.
|
|
|
|
|
|
In TARGET 4, the \ucode{scalr} selector used in the \kcode{target} region
|
|
has an implicit data-sharing attribute of firstprivate since it is a scalar.
|
|
Hence, the assigned value is not returned.
|
|
In TARGET 5, the associate name \ucode{a_scalr} is implicitly mapped and the
|
|
assigned value is returned to the host (default \kcode{tofrom} mapping behavior).
|
|
In TARGET 6, the use of the associate name and its selector in the \kcode{target}
|
|
region is conforming because the scalar firstprivate behavior of the selector
|
|
and the implicit mapping of the associate name are allowed.
|
|
At the end of the \kcode{target} region only the
|
|
associate name's value is returned to the host.
|
|
In TARGET 7, the selector and associate name appear in
|
|
an explicit mapping for the same \kcode{target} construct,
|
|
hence the code block is non-conforming.
|
|
|
|
\ffreenexample[5.1]{associate}{4}
|
|
\end{fortranspecific}
|
|
|