(j3.2006) (SC22WG5.4092) Standard intrinsics and coarrays
Tue Oct 20 10:06:25 EDT 2009
N.M. Maclaren wrote:
> In 13.5, Standard generic intrinsic procedures, after Table 13.1, add
> the new paragraphs:
In all the cases below, I assume you mean "unordered segments" rather
than "unordered images".
> EXECUTE_COMMAND_LINE shall not be be called in two unordered images.
I'm not sure this is a necessary restriction, but it does seem to leave
some unanswered questions. Even conforming to this restriction, many
images could have commands in concurrent execution because
EXECUTE_COMMAND_LINE may return before the launched command completes.
> RANDOM_SEED shall not be be called in two unordered images, nor
> shall RANDOM_NUMBER and RANDOM_SEED be called in two unordered
> images. It is processor dependent whether all images use a common
> generator or whether each image uses a separate one.
Disallowing RANDOM_NUMBER in concurrently executing segments severely
cripples using Fortran 2008 to parallelize a huge class of trivially
parallel applications - Monte Carlo codes. I think the last sentence
is OK. If a common generator is used, it is the vendor's responsibility
to have proper locks. (Vendors have already dealt with this issue in the
OpenMP context.) I would expect the normal case to be separate
generators for each image. The user chooses different seeds based on the
image number to avoid using the same sequence on each image. This has
been the mode of operation for MPI codes for a long time. People would
expect to use the same scheme with natively parallel codes in Fortran.
Asking them to rewrite the structure of these codes is neither
reasonable nor necessary.
> CPU_TIME, DATE_AND_TIME, GET_COMMAND, GET_COMMAND_ARGUMENT,
> GET_ENVIRONMENT_VARIABLE and SYSTEM_CLOCK may be called in unordered
Which is already the case if you say nothing.
, but it is processor dependent whether the results they return
> are dependent on which image calls them.
I think the real issue is that it is processor dependent whether the
clocks used to determine the returned values for CPU_TIME,
DATE_AND_TIME, and SYSTEM_CLOCK on each image are synchronized. A
statement along those lines might be useful.
I don't see how there would be a problem with GET_COMMAND or
GET_COMMAND_ARGUMENT. If an environment variable is never changed
during execution of the program, then I don't see an issue with
The more interesting case is if one segment sets an environment variable
(by calling a C library routine, for example), and then another segment
executes GET_ENVIRONMENT_VARIABLE expecting to get the value set by the
other segment. Is the action of setting the environment variable visible
to all images? If it is, then the even-half-aware programmer would
realize that the GET segment needs to execute after the SET segment, as
would be the case for ordinary Fortran variables. However, environment
variables are not covered by the segment ordering rules. For
environment variables, I think this is similar to the case where a
programmer opens a file on image 1, writes data, and closes the file,
and then on image 2 opens/reads/closes the file. The programmer has to
order the segments on image 1 and image 2 for this to make sense. Users
are responsible for ordering external actions when necessary.
> All other standard intrinsic procedures may be called in unordered
> images, subject only to their argument use following the rules in
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120
More information about the J3