Here is why it is called 'blocking async'. The term "blocking" means that it is safe to use the application buffer after the call returns. On a send, this means that when the call returns, you can safely re-use foo and send will still be correct, though it might not happen immediately. However, this won't say anything about how the data is received on the other end.
The flip-side to "blocking" is "non-blocking". Non-blocking does not make the guarantee above. When do we ever want to use non-blocking communication?
Source: MPI Guide and look for the text "Blocking vs. Non-blocking:"
grose
That might be what the word "blocking" means here, but why use the word "blocking", over any other word in English? It seems as arbitrary as calling it "strawberry async"
andymochi
@grose Hmm... makes sense. I do like strawberries...
As programmers, we intuitively think of "blocking" as "the call will only return once the data has been received by someone" (i.e. we have sent the data to someone). But they already have a word for that - synchronous. My guess is that "blocking" is referring to the memcpy operation that needs to be done to keep the data safe and queued to send.
From the perspective of the person who was writing an MPI implementation, I can see why they thought of it that way. For people using the API... not so much. Maybe "safe" and "unsafe" are better terms for the future?
BryceToTheCore
What is even more curious to me is that a simple google search for asynch blocking leads to several discussions that strongly associate asynchronous to non-blocking and contrast it to blocking communication.
I think that blocking is used over "strawberry", because the term strawberry does not quite sound like a canonical computer systems term.
Strawberry may actually be a good term to use, because if the system were to stop and eat a strawberry, then it would block all of the execution paths and therefore block everything. Therefore we could perhaps substitute the term "strawberry" for "blocking".
grose
@andymochi, so you're saying it's called "blocking", because it still "blocks" execution in order to do the memcpy? I mean, technically the other call has some work to do too... I guess less-so
kayvonf
@andimochi. Thanks for the clarification.
Blocking refers to the fact the calling thread is "blocked" until the argument buffer to send or recv is again available for modification/manipulation. In other works, the call does not return until it is safe to do so.
My perspective is the same as the web's. MPI's terminology is confusing (I used it here on the slide to be consistent with the MPI library, which you will use in assignment 3.) Typically folks use "non-blocking" and "asynchronous" interchangeably and "blocking" and "synchronous" interchangeably since the key fact is whether the calling thread's execution can be overlapped with the data communication, and that's true of both MPI's blocking async and non-blocking async variants of send. In the blocking async version the calling thread is not overlapped with the local buffer copy, but it is overlapped with the network communication (and hence the call is asynchronous). In the non-blocking aync send, the calling thread's execution is overlapped with both. In the blocking synchronous send, the calling thread never executes concurrently with any part of the send.
afa4
@andymochi: As mentioned in the MPI guide, you would want to use Non-blocking routines to overlap computation with communication and exploit possible performance gains (keeping in mind that it is unsafe to change the buffer contents until the send/receive was actually performed)
Here is why it is called 'blocking async'. The term "blocking" means that it is safe to use the application buffer after the call returns. On a send, this means that when the call returns, you can safely re-use foo and send will still be correct, though it might not happen immediately. However, this won't say anything about how the data is received on the other end.
The flip-side to "blocking" is "non-blocking". Non-blocking does not make the guarantee above. When do we ever want to use non-blocking communication?
Source: MPI Guide and look for the text "Blocking vs. Non-blocking:"
That might be what the word "blocking" means here, but why use the word "blocking", over any other word in English? It seems as arbitrary as calling it "strawberry async"
@grose Hmm... makes sense. I do like strawberries...
As programmers, we intuitively think of "blocking" as "the call will only return once the data has been received by someone" (i.e. we have sent the data to someone). But they already have a word for that - synchronous. My guess is that "blocking" is referring to the memcpy operation that needs to be done to keep the data safe and queued to send.
From the perspective of the person who was writing an MPI implementation, I can see why they thought of it that way. For people using the API... not so much. Maybe "safe" and "unsafe" are better terms for the future?
What is even more curious to me is that a simple google search for asynch blocking leads to several discussions that strongly associate asynchronous to non-blocking and contrast it to blocking communication.
I think that blocking is used over "strawberry", because the term strawberry does not quite sound like a canonical computer systems term.
Strawberry may actually be a good term to use, because if the system were to stop and eat a strawberry, then it would block all of the execution paths and therefore block everything. Therefore we could perhaps substitute the term "strawberry" for "blocking".
@andymochi, so you're saying it's called "blocking", because it still "blocks" execution in order to do the memcpy? I mean, technically the other call has some work to do too... I guess less-so
@andimochi. Thanks for the clarification.
Blocking refers to the fact the calling thread is "blocked" until the argument buffer to send or recv is again available for modification/manipulation. In other works, the call does not return until it is safe to do so.
My perspective is the same as the web's. MPI's terminology is confusing (I used it here on the slide to be consistent with the MPI library, which you will use in assignment 3.) Typically folks use "non-blocking" and "asynchronous" interchangeably and "blocking" and "synchronous" interchangeably since the key fact is whether the calling thread's execution can be overlapped with the data communication, and that's true of both MPI's blocking async and non-blocking async variants of send. In the blocking async version the calling thread is not overlapped with the local buffer copy, but it is overlapped with the network communication (and hence the call is asynchronous). In the non-blocking aync send, the calling thread's execution is overlapped with both. In the blocking synchronous send, the calling thread never executes concurrently with any part of the send.
@andymochi: As mentioned in the MPI guide, you would want to use Non-blocking routines to overlap computation with communication and exploit possible performance gains (keeping in mind that it is unsafe to change the buffer contents until the send/receive was actually performed)