Fixup VIS preconditions
VIS chapter preconditions include imprecise statements like the following:
All destination addresses must be global_ptr<T>’s originating from the same rank.
All source addresses must be global_ptr<T>’s originating from the same rank.
These should be cleaned up to use proper terminology ("originating from" is not a defined term).
Also for VIS rput_*_then_rpc:
Completion of the operation triggers a rpc_ff consisting of remote_completion_func bound with remote_completion_args to the rank owning the destination addresses.
Upon completion of the puts, the rank owning dest_base is delivered an rpc_ff of remote_completion_func called against remote_completion_args
"owning" should probably be "with affinity to", and the terminology for rpc_ff func/arg binding should be cleaned up and normalized
There's also an important secondary issue here that John just fixed for contiguous rput_then_rpc, which is how to handle the cases where the VIS payload was empty.
There are several distinct cases here:
- For fragmented and fragmented_regular: the iterators are empty, ie returned ZERO global_ptr<> destination addresses.
- For fragmented: the iterators returned a set of tuples where the size was always zero
- For fragmented_regular: src_run_length == dest_run_length == 0
- For strided: Dim template parameter is <= 0 (should probably be prohibited)
- For strided: Any element of extents[i] is zero
GASNet VIS accepts all of these cases and treats them as no-ops, but there is no _then_rpc variant in GASNet VIS.
Each of these cases in the UPC++ _then_rpc function needs to either be prohibited by precondition or (if it makes sense) ensure we have a well-defined semantic for which rank runs the rpc.
Comments (6)
-
reporter -
reporter Add to the fix-it list for rget_fragmented(regular):
a sequence of destination addresses of
T const *
...
DestIter could be an iterator over elements of typestd::pair<T const*, std::size_t>
in both places should be
T *
(no const) -
Account Deleted I'm going with adding the explicit recipient.
-
Account Deleted - changed status to resolved
-
reporter - changed status to open
New recipient argument looks good.
3-4 of the other issues I raised above are still unresolved:
- Use of undefined term "originating from"
- Use of undefined term "owning"
- "destination addresses of (T const *)"
- rpc_ff func/arg binding text should possibly be normalized to match similar text elsewhere
The first two involve preconditions that should be altered to refer to "affinity" or a pointer.where().
-
Account Deleted - changed status to resolved
Wow thank you. Sloppy sloppy.
- Log in to comment
One possible resolution to the VIS_then_rpc target ambiguity is to add a
intrank_t recipient
argument to all the VIS rput*_then_rpc functions, and require that all global_ptr<>'s in the metadata have.where() == recipient
. This adds a small amount of redundancy to the common case, but with this change, we always have a well-defined target for the rpc, even for the corner cases where the VIS payload turns out to be empty.