Since MPI_Probe is part of MPI-1, and I don't believe that MPI-2 plans
to deprecate it, I presume that it is still fully available to users.
But, in any case, I have already stated that I am not defining a new type
of probe (RMA_PROBE), and the end of my message suggests a better way
that does not even use PROBE.
> ...If you are writing an agent
> to handle put/get-s, you don't need to write it at the MPI
> level.
In the PUT/ACCESS proposal, you do.
> ...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.
Hack the source of MPI? or of the MPI application?
> I understand that this is an illustration of a possible agent though.
My message was written in the following context:
(A) If PUT and GET semantics support 3rd-party communication (i.e. they
allow two different processes to perform 1-sided communications to a
third process without any involvement from the third process, thereby
effectively passing data between the two processes through the third
process), then some architectures will require that MPI have an agent
(or daemon) running at all times near the third process to watch for
GETs and PUTs.
(B) Since I expect that 3rd-party communications will be relatively rare,
I have not proposed them in the PUT/ACCEPT proposal. This means that
if the PUT/ACCEPT proposal is accepted, MPI does not require agents,
for any architecture (unless they are required for some other part of
MPI that I don't know about).
(C) Users can still do everything that they could have done if 3rd-party
communication *was* supported, by building their own agent (daemon), in
the way shown in the message, if they need one.
This provides the advantages of 3rd-party communication for those users that
want it, without the overhead of a daemon for those users who don't need it.
> 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 have already suggested another way, at the end of my previous message.
> 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).
My previous message does not suggest the use of any new message types or
handling anything behind the scenes.
If you don't believe in the reasoning (i.e. A, B, C) above, please let me
know why and I will try to defend it. (Until I need to start packing for the
meeting.)
-Dave
===============================================================================
David C. DiNucci | MRJ, Inc., Rsrch Scntst |USMail: NASA Ames Rsrch Ctr
dinucci@nas.nasa.gov| NAS (Num. Aerospace Sim.)| M/S T27A-2
(415)604-4430 | Parallel Tools Group | Moffett Field, CA 94035