Adding Fortran bind(C) support for basic OpenSHMEM routines in a separate document

[naveen-rn]

Problem

As per #194, we are planning to separate the main Fortran replacement interface proposal into multiple smaller parts. This issue tracks the first part of the proposal - to add and support the initial list of Fortran bind(C) routines.

List of supported OpenSHMEM interface

The following are the list of planned OpenSHMEM routines available in the Fortran bind(C) interface.

shmem_init ()	shmem_ctx_create ()	atomic_swap	shmem_wait_until()
shmem_finalize ()	shmem_ctx_destroy ()	atomic_fetch_add	barrier
shmem_my_pe ()	shmem_putmem()	atomic_fetch_inc	sync
shmem_n_pes ()	shmem_putmem_nbi()	atomic_fetch_and	all-to-all
shmem_global_exit ()	shmem_getmem()	atomic_fetch_or	all-to-alls
shmem_init_thread ()	shmem_getmem_nbi()	atomic_fetch_xor	broadcast
shmem_query_thread	atomic_fetch	shmem_quiet ()	reduce
shmem_malloc ()	atomic_set	shmem_fence ()	collect
shmem_free ()	atomic_cswap	shmem_test ()	fcollect

Changes

All these routines will be added as part of a separate document and not be included in the main OpenSHMEM specification.

[jeffhammond]

What's the value of standardizing this versus the interested parties providing an implementation to the community as OSS?

There is a real cost to standardization in the form of our time. I'd like to see the implementation in the wild and some evidence that we need more than one implementation of the same API. If there is only going to be one implementation, then there is no need to spend time on standardization.

[naveen-rn]

If you look at the proposal - we have tried to split it as three different sub-levels:

1. RM all the existing FTN support - DONE
2. Introduce Fortran Bind(C) based base support - This Adding Fortran bind(C) support for basic OpenSHMEM routines in a separate document #249 issue
3. Introduce the use of standard Coarray features with OpenSHMEM to make (2) more clean - Issue Adding support for interoperability with Fortran Coarrays #252

Though our goal is just to have (3) in the spec - introducing the changes as multiple smaller items makes it little easier for standardization. To answer why we need (3) as you have asked in #252 (comment):

We are not expecting users to program both Coarrays and OpenSHMEM together. But, we are trying to make use of standard language features like the coarrays as OpenSHMEM-aware symmetric heap objects. This is similar to the use of global/static variable in C. IMO, this will make it easier for FTN users to adopt OpenSHMEM.

So, addressing the interoperability comes from trying to make the spec more usable. Once we allow using coarrays as SHEAP - then it is required for the OpenSHMEM spec to address the sequential consistency and memory ordering rules of mixing both OpenSHMEM and FTN Coarray features together. This is same as how we are addressing the load/store interoperability with general OpenSHMEM RMA/AMO semantics in C-bindings.

And, again this also the reason why we can't simply maintain a OSS library. To implement (3) - we need more information on the underlying memory management engine in different CAF and OpenSHMEM implementations. We can discuss this further if required.

All said - I agree with the effort statement. That is why the progress is very slow.

Related paper: https://dl.acm.org/doi/10.1145/3418084
WIP branch: https://github.com/naveen-rn/specification/tree/ftn08 - needs update