(j3.2006) (SC22WG5.4093) [ukfortran] Standard intrinsics and coarrays

[N.M. Maclaren]

On Oct 20 2009, Bill Long wrote:
>
>In all the cases below, I assume you mean "unordered segments" rather 
>than "unordered images".

Oops, yes.  Thanks.

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

Thanks.  I need to think on that one :-(  I can guarantee that it IS
necessary, at least under zOS and possibly on the Blue Gene, but it might
be necessary to restrict it to image one.  On distributed systems, the
effect of doing it is likely to vary in 'interesting' ways between images.

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

That's what I meant to specify.  What I want to exclude is one segment
calling RANDOM_SEED and an unordered one calling RANDOM_NUMBER.  That's
at best processor dependent, isn't a clever piece of programming, and is
sometimes a pain in the neck to implement.  Consider, for example, an
implementation where an initial value of zero selects the use of /dev/random
and other values select a pseudo-random generator.  It's a very reasonable
specification.

>(Vendors have already dealt with this issue in the OpenMP context.)

A heck of a lot of such systems do some very weird things when you get
race conditions between initialising a state and using it.  This rarely
causes trouble because sane programmers don't initialise state in parallel
code - they know it's asking for trouble.

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

Yes, but that involves specifying what "synchronized" means - and it's
by no means obvious.  Also, it isn't clear whether CPU_TIME returns the
per image CPU time or per program CPU time - and there are systems where
only one is feasible.  And there are potential differences in the initial
offset for SYSTEM_CLOCK.  MPI has already addressed this one, and says
much what I say.

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

What about distributed memory, as is already supported by g95 under Cocon?
MPI has already addressed this one, and says much what I say.

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

Oh, yes, indeed :-(  But that isn't currently the Fortran standard's
problem.  Thinking about zOS and that one makes my head hurt ....

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

I quite agree.

Regards,
Nick.