https://svn.boost.org/trac10/ticket/12828 <p> Posting two irecv on the same sender/tag of a non-primitive data type result in a crash. The problem is the 'two phase' receive, where the actual data irecv is posted only during wait, once the size is known. </p> <p> Basically the sender will always send in this order (regardless if blocking or not) </p> <pre class="wiki">send(&amp;msg0.size) send(msg0.buffer) send(&amp;msg1.size) send(msg1.buffer) </pre><p> However, a nonblocking receiver will post: </p> <pre class="wiki">irecv(&amp;msg0.size) irecv(&amp;msg1.size) // WaitAll or the likes irecv(msg0.buffer) irecv(msg1.buffer) </pre><p> A trivial example that crashes is attached. </p> <p> MPI has a well-defined determinist order guarantee (Section 3.5), and also specifically "Nonblocking communication operations are ordered according to the execution order of the calls that initiate the communication." (Section 3.7.4) </p> <p> I cannot find any explanation of this severe limitation in the boost documentation. </p> <p> I could think of two possible ways out: </p> <p> Create hidden additional duplicate communicators for each boost::mpi::communicator so that two different communicators are used for sending size &amp; buffer. That seems to be quite clean, but requires lots of changes to the interface. </p> <p> One could also split the tag-space in half and use the upper half for the additional messages. That of course is really nasty and can result in non standards conforming behavior. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/12828 Trac 1.4.3 anonymous Fri, 10 Feb 2017 15:54:40 GMT https://svn.boost.org/trac10/ticket/12828 https://svn.boost.org/trac10/ticket/12828 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">ipanic.cpp</span> </li> </ul> Ticket