[mpich-discuss] //Ssend(...) safe?

[Rajeev Thakur]

Data from the first send will match the first receive; data from the second
send will match the second receive. Modifications made to the send buffer
after the first send returns will not affect the data received by the
matching first receive in any case. It doesn't matter if you use Ssend or
just regular Send.  

Rajeev 

> -----Original Message-----
> From: mpich-discuss-bounces at mcs.anl.gov 
> [mailto:mpich-discuss-bounces at mcs.anl.gov] On Behalf Of Sören 
> Freudiger
> Sent: Sunday, November 16, 2008 12:40 PM
> To: mpich-discuss at mcs.anl.gov
> Subject: [mpich-discuss] //Ssend(...) safe?
> 
> Hi @All
> A hopefully very easy question. I just want to ensure that 
> there's no misunderstanding:
> 
> //////////////////////////////////////////////////////////////
> ///////////////////
> if(rank==0)
> {
>    MPI::Request request = comm.Irecv(recvData, recvData.size, 
> MPI__INT, 1, 100)
>    /* do something */
>    request.Wait();
>    request = comm.Irecv(...);
>    /* do something */
>    request.Wait();
> }
> else
> {
>    /* do something */
>    comm.Ssend(sendData, sendData.size, MPI::INT, 0, 100);
>    sendData[0] = 100;
>    comm.Ssend(sendData, sendData.size, MPI::INT, 0, 100);         
> }
>  
> comm.Barrier();
> //////////////////////////////////////////////////////////////
> ///////////////////
> 
> I read somewhere:
> 
> " When a synchronous mode send operation is completed, the 
> sending process may assume the destination process has begun 
> receiving the message. The destination process need not be 
> done receiving the message, but it must have begun receiving 
> the message. "
> 
> Does that mean that under certain circumstances sendData[0] = 
> 100; changes the data that is send at my first comm.Ssend(..) call? 
> I think it's like that:
> On the send side the send operation is completed as soon as 
> the other side has started the receiving process. 
> Nevertheless if all Data has been received on the other side 
> there's no risk to write into the send buffer at the sending 
> side again. That means: no chance that sendData[0] = 100; at 
> first Ssend-operation. Am I correct?
> 
> Best,
> DarkAnn
> 
> PS: I'm using Ssend, because possibly my send-call happens 
> before my Irecv has been called. That means Rsend results in 
> undefined behaivoir and that means standard Send shouldn't 
> been used because reday send could be implemented for that one.
>