Non-blocking atomic fetch is not non-blocking

[wrrobin]

Non-blocking atomic fetch uses fi_fetch_atomic with DELIVERY_COMPLETE flag. This ensures that the value is fetched before returning. Should it use the FI_INJECT without any completion semantics?

Also, for the same reason, does the blocking atomic fetch require a call to get_wait?

[markbrown314]

I am assuming this is the same issue: #1061

[avincigu]

@wrrobin I am looking at shmem_transport_fetch_atomic_nbi function in transport_ofi.h and I see that in the fi_fetch_atomicmsg call the argument passed is FI_INJECT. Has these bug already been fixed then or am I missing something?

[wrrobin]

@avincigu - IIRC, this was fixed only for CXI provider. For other providers, the path may not have been optimized.

[avincigu]

Thanks @wrrobin

So OFI uses that line of code I described so I think that one checks out. UCX is calling which I also assume in non-blocking. Portals has this comment "transport_fetch_atomic already buffers the source argument" and then calls a regular fetch atomic so I am assuming the comment is accurate. The onnly place I don't know if we are calling something that is blocking is in shmem_shr_transport_fetch_atomic, I don't see any non-blocking stuff there and in the code you reference here: #1062

The rest seems fine, I think.