How does SENDPROBE work? Is it simply a lock to data? If the SENDPROBE is not returned and thread is willing to modify 'foo' then isn't the thread is still blocked?

This comment was marked helpful 0 times.

'SENDPROBE(h)' is simply a call that returns tells the calling program if the message referred to be the handle h has been successfully sent by the messaging system. If SENDPROBE indicates the message has not been sent, then the application should not modify the contents of foo.

Logically, the following pseudocode that uses a non-blocking send followed by a SENDPROBE is equivalent to a blocking send.

h = NON_BLOCKING_SEND(foo);
while (!SENDPROBE(h)) {}

This comment was marked helpful 1 times.

So why exactly do we need to even check that the message has been sent? Once we have copied the data into the network buffer, we should be free to modify foo as we wish since there is a copy of foo in the network buffer and it is now the responsibility of the network to transfer the information.

The only exception I can think of is that for some reason, the network buffer might need to read from foo again - though I can't think of why this would ever need to happen - and if foo is modified, then we have a problem.

This comment was marked helpful 0 times.

@rokhinip: How do you know that the data has been sent? That's the purpose of SENDPROBE. (Technically, it is even more conservative and it returns true if the message has been received.)

This comment was marked helpful 0 times.

I suppose we can't quite assume that the network protocol we are using should guarantee that foo has been sent then?

This comment was marked helpful 0 times.

"Non-blocking" and "asynchronous" mean the same thing to me, so to disambiguate: here, the SEND call is asynchronous and returns immediately; the RECV call is non-blocking and returns immediately (and requires checks to guarantee the data has actually been received.)

On the previous slide, "blocking asynchronous" again means that the SEND call returns immediately but that the RECV call blocks.

This comment was marked helpful 0 times.

It seems to me that there is a slight difference between blocking asynchronous and non-blocking asynchronous, in that blocking asynchronous will wait for the data to be transferred into the network buffers but will not wait for the acknowledgements. Non-blocking asynchronous waits for neither.

This comment was marked helpful 0 times.