Fortran coarray collectives: non-coarray write visibility across images without sync memory

Answer first

A non-coarray write on image 1 is never visible on image 2, with or without a collective. Non-coarray variables are image-private by definition. Only coarray objects can be shared between images, and a collective synchronizes only the coarray accesses that participate in it. Therefore a local write before co_sum, co_max, co_min or co_reduce is not guaranteed to be visible to another image after the collective returns, and in fact cannot be visible at all without a coarray transfer.

Confirmed facts vs likely explanation

Confirmed: The research brief states non-coarray variables are image-private; a write on one image is invisible to all other images. Only coarray objects are candidates for inter-image sharing and must be accessed through coarray syntax. A sync memory or sync all is required to make a coarray write visible; without it other images may see stale values. Compilers treat non-coarray writes as local and generate no inter-image communication.

Likely explanation for the ambiguity you see: The Fortran 2018/2023 standard describes collectives as image-control statements with synchronization for the collective operation. The strength of that synchronization for coarray data is implementation-defined in practice: some compilers document acquire/release semantics for coarray accesses, others behave as a stronger barrier. The standard does not define a full memory fence for non-coarray data, and there is no conformance test for ordering of local variables across images.

Compiler-agnostic test pattern

1. Declare a non-coarray integer local_val and a coarray integer co_val[*].
2. On image 1 set local_val = 42 and co_val = 1, then call a collective on co_val.
3. On image 2 print local_val after the collective returns.
4. Expect local_val to remain its initial value on image 2. Repeat with a coarray read to confirm coarray visibility changes only after an explicit sync memory.

Run with two images using -fcoarray=lib or equivalent. This isolates image-private behavior from collective ordering.

Mixed language ordering

C11 atomic_thread_fence can order C memory relative to a C call, but it cannot make a Fortran non-coarray variable visible on another image. Inter-image visibility requires a coarray transfer and Fortran synchronization. Using a fence around a collective may help order C and Fortran accesses within the same image, but it does not publish local Fortran data to other images.

One missing diagnostic detail that changes the recommendation: are you intending to communicate the value via a coarray argument to the collective, or do you expect the local variable itself to be observable on another image? If the former, use a coarray and explicit sync; if the latter, the design is not portable.