You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/comm.rst
+20-4Lines changed: 20 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -87,10 +87,12 @@ Send and Receive
87
87
88
88
These are the most basic communication operations, and need to be paired: one process sends data and the other process receives the data.
89
89
90
-
There are some subtleties here that one should be aware of.
91
-
Unlike MPI, Aluminum does not support tagged messages.
92
-
You should properly order your sends and receives, so that you start your sends and receives in the same order.
93
-
Finally, note that sends may (but are not guaranteed) to complete *before* the data has been sent or before it has been received (it is, however, safe to read or modify a send buffer after the send has completed).
90
+
There are some subtleties here that one should be aware of:
91
+
92
+
* Unlike MPI, Aluminum does not support tagged messages.
93
+
* Also unlike MPI, a receive will only match a send with the exact same ``count`` (whereas MPI treats the receive count as an upper bound).
94
+
* You should properly order your sends and receives, so that you start your sends and receives in the same order.
95
+
* Finally, note that sends may (but are not guaranteed) to complete *before* the data has been sent or before it has been received (it is, however, safe to read or modify a send buffer after the send has completed).
94
96
95
97
There are no special in-place versions of send or receive, as they only have one buffer argument.
96
98
@@ -116,6 +118,20 @@ There is an in-place version of ``SendRecv`` (this is similar to ``MPI_Sendrecv_
116
118
* :cpp:func:`Al::SendRecv()`
117
119
* :cpp:func:`Al::NonblockingSendRecv()`
118
120
121
+
.. _multisendrecv
122
+
123
+
MultiSendRecv
124
+
^^^^^^^^^^^^^
125
+
126
+
This implements an arbitrary sequence of ``Send`` and ``Recv`` operations as a single operation.
127
+
This is similar to an ``Alltoall`` collective, but does not require that all ranks in a communicator participate.
128
+
Likewise, unlike a sequence of ``SendRecv`` operations, this does not require all ranks to both send and receive; i.e., there may be asymmetric communication.
129
+
130
+
There is an in-place version of ``MultiSendRecv``, which differs slightly from a regular ``MultiSendRecv``: It functions exactly like a sequence of in-place ``SendRecv`` operations.
0 commit comments