[Bug fortran/88076] Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076

--- Comment #7 from Nicolas Koenig <koenigni at gcc dot gnu.org> ---
(In reply to Damian Rouson from comment #5)
> This is an exciting idea.  When I gave some thought to writing a
> shared-memory alternative coarray ABI, it seemed to me that pthreads would
> be a better choice than OpenMP.  Part of the problem is that I was
> considering writing the implementation in Fortran, and OpenMP lacked support
> several modern Fortran features, including several object-oriented
> programming features.  That of course won't be an issue for you, however,
> assuming you're going to write the implementation in C.  I was going to
> leverage "forthreads," an open-source Fortran 20003 interface to pthreads. 
> One thing that I think would be a major benefit of having a Fortran
> implementation of the library is that it greatly expand the potential
> community of contributors to include more of the users of the compiler.
> 

I actually opted to use multiprocessing with shared memory (shm_open() & co)
instead of multithreading, since it will be much easier and faster with static
variables, of which gfortran makes extensive use. Also, it greatly simplifies
interoperability with OpenMP. The only real downsides I can think of are slower
spinup times (~10000 cycles for processes vs. ~1000 for threads), far slower
context switches (only a problem if more more images than cores are used) and
slower allocation, since at the moment a mmap() call is needed for each one
(the allocator tracks the offset and size in the memfile instead of the
mmap()'ed memory regions. If this is to slow, I can just cache the pointers).
As for writting it in fortran, see below :)

>
> Another important consideration is whether to use the current gfortran
> descriptors as arguments in the library functions (as is currently used) or
> instead to use the Fortran 2018 CFI descriptors for which Paul recently
> committed support.  If you go with the current gfortran descriptors, then
> there could be a lot of code to rewrite if gfortran later adopts the
> standard descriptors internally.  Paul's recent commit adds functions that
> can translate between the gfortran and standard descriptors. I have a
> volunteer who I'm hoping will use the translation functions to develop a
> new, alternative coarray ABI that accepts the standard descriptors.
> 

I actually think it would be best not to turn it into a separate library but
instead integrate it into libgfortran. This way, it will not be necessary to
install a seperate library and thereby make it easier for people to start using
coarrays. Therefore, it would make sense to use the libgfortran descriptors.

>
> On another note mentioned earlier in this PR, I believe it will be necessary
> to fork all threads at the beginning of execution and not join them at the
> end.  Section 5.3.5 of the Fortran 2018 standard states, "Following the
> creation of a fixed number of images, execution begins on each image."
> Assuming there is a one-to-one correspondence between images and threads, I
> read that as implying that a fixed number of threads have to be set up
> before any one thread can execute.  (Possibly there could also be additional
> non-image threads that get forked later also though.) 

At the moment, sync_all() is called after image creation.

> I recall seeing several interesting papers from 10-15 years ago on SPMD-style
> programming using threads (OpenMP) so a literature search on this topic be 
> useful to read.