Hi Thomas,
> I have a few questions.
>
> First, I see that your patch series does not use gfortran's descriptors
> for accessing coarrays via shared memory, as the original work by
> Nicolas did. Can you comment on that?
The ABI for invoking coarray functionality is sufficient for doing the job.
Modifying the compiler to access coarrays directly, i.e., having implementation
detail on a certain library in the compiler did not appeal to me. Furthermore
has the new library in conjunction with the other library available the
potential to get to a stable and maintained ABI. Having another ABI in the
compiler would have lead to two badly maintained ones (in my opinion). I
therefore decided to just have one ABI and figured that all that is needed can
be done in a library. This also allows link-time polymorphism. And last but not
least, there is a major rework on the array descriptor going on and that would
have had the potential to conflict with my work.
> Second, how did you ensure that the library is free from race
> conditions?
The library itself uses mutexes where needed. Additionally are there no
segments where two locks are held at the same time (when I remember correctly).
When you mean races on coarray's data: It is not. That is the user's
responsibility like it is with the other coarray implementation.
> Third, the code "as is" will (looking at this in a cursory way)
> will probly fail on systems where you cannot increase mmap()ed
> regsions, such as macOS or Windows. Dominique pointed this out
> back then.
The code has no support for increasing the shared (mmap()ed) region. And I
don't think it is necessary at this state of the development. One can chose a
very large shared memory size on program startup. To my knowledge most systems
will map in/allocate the pages as needed. When there is no space left in main
memory, then also growing a shared region would not have worked. Therefore I
think this is fine. Do you have different knowledge?
I deem this library fit for educational and research use, where small to medium
sized problems are researched. I do not expect it to support a long term running
application, because is does not join adjacent blocks in the shared memory upon
free. I.e. the shared memory will get fragmented and at some time no shared
memory can be allocated anymore. Furthermore is there no check in the library,
when it tries to use memory beyond the allocated size. This is the first shot
on having a shared memory coarray library. Therefore in my opinion it should be
usable but not perfect in all aspects. Yes, there will be bugs and yes it can
be improved when need by. But for the time being, I think what I presented is
quite usable.
Did that answer your questions?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
