RE: 3rd-party comm in PUT/ACCEPT proposal using custom agents

Shane Hebert (shane@ERC.MsState.Edu)
Tue, 16 Jul 1996 17:08:16 -0500

-] Perhaps the most important aspect of the agent is that it block and do
-] nothing most of the time -- i.e. unless a process is attempting to communicate
-] with it. PROBE works well for this purpose. (Earlier, I proposed using a new
-] RMA_PROBE. It now appears that the standard PROBE will suffice, by extending
-] the STATUS argument returned from it to include an "MPI_OP" field which denotes
-] whether a GET, PUT, GETHOLD, PUTHOLD, or SEND is in the queue. It may not
-] be necessary to delineate GETHOLD from GET and PUTHOLD from PUT.)

I don't think the MPI_Probe or MPI_IProbe calls should be
used *ever* -- much less here. I hope we don't define a
new type of probe (RMA_PROBE) either. If you are writing an agent
to handle put/get-s, you don't need to write it at the MPI
level. The only time you would use an MPI program to be an
agent is if you are a user of an MPI implementation that doesn't
handle put/get-s the way you want to do it (or at all) and you
are making a work-around because you can't hack the source.
I understand that this is an illustration of a possible agent though.
We have also put thought into the design of an agent that is written
at a much lower level that MPI (at the device level).
I agree that any agent written should be able to block and use
no CPU time unless needed. Hopefully other ways than using
any of the 'Probe' functions can be found on most machines.
I'll not use up bandwidth here but I'm willing to discuss ideas
for agents with anyone off-line (and/or) over email. Some ideas
are pretty simple though -- define new message types that are
handled 'behind the scenes' by MPI (with or without the use of
threads).

Shane