[4.7, RFC, Fortran] Coarray: Moving towards real parallelization

[Tobias Burnus]

On 03/04/2011 05:57 PM, Ralf Wildenhues wrote:
>>>>    MPI_Init (argc, argv);
>>> If you're relying on MPI2 anyway, I suggest you try to not limit your
>>> users to not use MPI themselves.  So please use MPI_Initialized, and
>>> don't finalize if the library isn't responsible.
>> Well, the current implementation relies on an early initialization
>> by the front end, the compiler generates a main program, which
>> initializes the library. Thus, there is no chance for the user to
>> call MPI earlier.
> Ouch.  That then also means that the user will not be able to use MPI
> herself in the program
> for them, MPI_Init first thing in main is the
> documented way to initialize MPI, but it will invoke undefined behavior
> with above setup.

Well, if I look in the yellow book also states that one should use 
MPI_Initialized to check whether it is already initialized. If they want 
to combine MPI with coarrays they have to be prepared that for coarrays 
also MPI might be used as backend communication library. That's always 
the problem as soon as one mixes parallelization schemes (OpenMP, 
pthread, MPI, GASNet, ARMCI/GA, shmem, ...) or different programming 
languages (C, UPC, C++, Ada, Pascal, go, ...): one needs to be careful, 
may need to add additional checks, and possibly some function calls to 
initialize libraries.

Besides, I do not see any possibility to prevent the issue, except using 
a different communication library than MPI. The MPI initialization can 
happen any time in the program, e.g. deep in some linked library - or it 
might never happen. Thus, it makes sense to initialize the coarray 
library early - which is before the actual user code starts.

Note further that the front end does not know which coarray 
communication library is linked. It can be the MPI one, it can be a stub 
one (effectively single image), or it could be pthread or some other 
library such as GASNet or ARMCI, which might sometimes also use MPI as 
backend.

However, in order to make it easier to use the library with a 
non-Fortran main program, I have added a MPI_Initialized check and I 
will later document in gfortran.texi how to initialize the library in 
that case.

>> However, one should think of having a coarray
>> program, where the main program is not a Fortran program. In that
>> case, the parallelization library could be called later. However,
>> one then runs into issues like initializing the library. I think one
>> has to think carefully about that - but supporting coarrays with a
>> non-Fortran main program causes several subtle issues.
> Could be; but I think you should aim for something like that in the end,
> it would be significantly more user-friendly.

I do not see any difference to the status quo, except for documenting 
the library function and for adding an MPI_Initialized. That won't be 
userfriendly but mixed-language programming is rarely user friendly.

Tobias

PS: Actually, one could delay the initialization of the library to the 
first use, but as one does not know when it happened and as an MPI_Init 
could come (hidden via a function call) at any point, one would 
effectively need to add before every communication a check whether the 
library is initialized, which would kill the performance and would still 
not help if the first coarray communication comes before the the 
MPI_Init ...