(j3.2006) (SC22WG5.4092) Standard intrinsics and coarrays

[Bill Long]

N.M. Maclaren wrote:

> Proposal:
> 
> 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
>     images

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 
GET_ENVIRONMENT_VARIABLE either.

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.

Cheers,
Bill



> 
>     All other standard intrinsic procedures may be called in unordered
>     images, subject only to their argument use following the rules in
>     8.5.2.
> 
> 


-- 
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