Personally, I think nonpersistent nonblocking generalized requests are
sufficient.
Now, I would prefer to call the new function MPI_META_REQUEST_IDO instead
of
MPI_IMETA_REQUEST_DO.
Jean-Pierre
(Embedded
image moved lederman @ cs.wisc.edu
to file: 12/03/96 08:40 AM
PIC20579.PCX)
To: mpi-external @ mcs.anl.gov
cc: (bcc: Jean-Pierre Prost/Watson/IBM Research)
Subject: tabled issues for generalized
requests
--0__=jlQHYOlCtHXykdPJ3zxRY18455jmOLf8vKLRC2qyQSQi7OdjHHhD3pYO
Well, SC96 has come and gone and now my mind (after a nice break)
returns to thinking about finishing up the external chapter. We are
going to have to move on this since we need to have the chapter in
good shape for the next meeting. The first topic I would like to work
on is generalized requests. A number of different issues were raised
before SC96 that were tabled. I would like to start with the high
level ones and work our way to semantics once we decide the big
picture.
Several people commented on the fact that extra_state is now in the
MPI_META_REQUEST_CREATE instead of where it is started. This was done
so we could reuse the current MPI_START function. The consequence is
that it is much harder to keep unique state for each instantiation of
a generalized request (such as having one generalized request to do lots
of different I/O writes). We started down a lot of these paths to get
the complete symmetry of the 4 possible combinations of persistent &
nonpersistent; blocking & nonblocking. I am beginning to wonder if we
really need this. Here is my current thinking:
Why have persistent? In the case of point-to-point or collective, you
get the pointer arguments, comm, etc. Doing the checks and
optimizations once up front can buy you something. However, in
generalized requests, all the functions are given at the
MPI_META_REQUEST_CREATE call and the MPI_META_REQUEST_INIT mearly
takes the meta_req and gives you back a persistent request. I'm not
sure a lot of useful optimization can go on here. If a generalized
request wants to be persistent then it could use extra_state to pass
this information and/or cache on the related communicator.
Why have blocking? Clearly you can get the blocking version by doing
the nonblocking followed by a wait. Why did we not do this elsewhere
in MPI? In the case of collective we didn't want all the non-blocking
versions because then you can have multiple ones active at a time.
Clearly this does not hold for generalized requests. In
point-to-point I think it was to avoid needing the request argument.
It was viewed as inconvenient in these common functions and had some
overhead. In generalized requests, the overhead probably isn't an
issue and the added complexity of the request argument is minimal
compared to everything else.
If we give up on symmetry, then the above argument supports having
nonpersistent, nonblocking only. We could leave
MPI_META_REQUEST_CREATE and replace MPI_META_REQUEST_INIT with a
function to take a meta_req and make a non-blocking request out of it.
Call that function MPI_IMETA_REQUEST_DO (or a better name!). This
also allows for putting the extra_state in this functions since it is
specific to generalized reqeusts. It also allows for making a
meta_req into a new object if we want since there is no need to have
it as a MPI_Request to be compatible for the MPI_START call. (This is
if we want to do this as was suggested.)
Ok. this note is already too long. What do people think about
limiting generalized requests to nonpersistent, nonblocking only?
Steve
##########################################
Jean-Pierre Prost
IBM T.J. Watson Research Center
PO Box 218
Yorktown Heights, NY 10598
USA
Phone: (914) 945 3225 - Fax: (914) 945 2141
Lotus Notes: Jean-Pierre Prost @ IBM Research
Internet: jpprost@watson.ibm.com
URL: http://www.research.ibm.com/people/p/prost/
##########################################
--0__=jlQHYOlCtHXykdPJ3zxRY18455jmOLf8vKLRC2qyQSQi7OdjHHhD3pYO
Content-type: application/octet-stream;
name="PIC20579.PCX"
Content-transfer-encoding: base64
CgUBCAAAAABoACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAABaQABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAD1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPH
E8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sTzRPHE8MTwhP1E9sT
zRPHE8MTwhPwEwzIBgzYE8wTxhPDE8IT7hPOBtcTzBPGE8MTE+wTwgbCBwbCEgbCEgbCEsUG1hPL
E8YTwxMT6hMMwgYHwgLCAwISwgfEEsMCwwbVE8sTxRPDExPpE8MGAwcCBwMCwhLDB8ISwgISwgLD
BtUTyhPFE8MTE+gTwgIHA8ICEw4DDgLDE8USwwLCEMIG1BPKE8UTwxMT5xMCAwcDAg4TDgITwgIS
D8ISD8ISBRICEcICwwbUE8oTxRPCExPmEwYCBwMCDgIOwgLDExITEhPCEg8GxgLDBtMMDAfJE8QT
whMT5hMGwwITBgMCDhLFEw8SE8ISBgIDwhIDEsMGB9MDxwwHxRPDExPlEwYHAhESAg8CwhMPwhMP
xBMPxRIQwgIDAgMCBtMDxwPEDAfDE8IT4RMHwwzCBgLCEhMCDxLIE8MSD8MSwwIQAwIDBgfSDMkD
wgPCDAfCExPbEwfGDMIDDAIHERITEhMSwxMPwxMPwxPDEgIDAgMCwwMCBgzREwfHDMYDDMITE9YT
B8UMyAMGB8ICBhLDAsYTEhMSExIPwhIHAgcCAwUQAgYRBgfSE8UTB8QMwgMMwhMT0hMHxAzLA8IM
BsISDxESExITAw4DxBMSExITwxICBwPCAsMDDMIGB9ITyRMHwwzCExPPEwfDDMkDxQwHwhMGBxIT
AhECEwMOAg7DExITDxMPwxIDAgMCBwMCDAYRBgfSE8kTwhPCDMITE8wTB8MMxwPEDMIHxxMGxBLD
Ag4DDgIGwg/IEgIDwgIDAgwCEMIGB9ITyRMHDAcMwhMTyhMHwgzGA8MMwgfMEwYHwhLCEAIOAg4C
DhDDAhIPxhIFAgXDAgUCEQYH0hPHEwfCDAcPDMITE8gTB8IMxQPDDAfQEwbDEhDEAhAOEA4QwgLG
EgcSBhIGBcMCBcIGB9ATB8UMEwfCDA8HDwwHwhMTxhMHwgzEA8MMB9MTBgfCEhADEMICDhAOEMIC
EQIDxxIGBwbCAgUCEQYHyxMHxAwHwhMHEwzCEwcPBw8MB8MTE8UTBwzEA8IMB9YTBsQSEAMCA8UC
EQIDAgPDEgcSBgfCBgUQAhDCBgfGEwfEDAfGE8INEwzCEw8HwgwHwxPCE8QTBwzDA8IMB9gTBgfE
EhACEMYCEQIDAsQSBhLDBsICEALCBgfCEwfDDAfKEwfCDRMHwhPCDAfEE8ITE8MTBwzCA8IMB9oT
DBIHwxLDDBEDxQIDAgPDEgYSBgfCBgIQAhAGDAfCEwzDE8MHyRMHwhPCBxMHxRPDExPDEwzCAwwH
3RMGxxICEQPDAgMCA8MSBhIGBwYMBhACEAIGDMMTDBPCB8YTwwfHEwfGE8MTwhPDEwwDDAfeEwYH
xxICEQPDAgMCwhIGEgYHBgwGEAIQAsIGB8MTDMYTwwfKEwzGE8MTwhPDE8IMB98TDBLCB8USAgMR
xAISB8ISBgcGDAYQBhAGEAYMB8MMB8kTwwfHEwzGE8MTwhPDEwwPwgzfEwYSB8ISB8ISAhECAwID
EgcSBwYHBgwGEAYQxgzDD8IHxRPDB8kTBwzGE8MTwhPDEwzDD8QM3BPCBhIGwxIGAhECAwIHBgcG
yAzJDxMHzRMHwwwHxxPDE8ITwxMHDMYPxwwH1BMGEgYSBhLLDM4PwwwTDMcTwgfEDAfJE8QTwhMT
xBMHwgzLD9sM0w/GDAfDEwzDEwfEDAfLE8YTwxMTxhMHxAztD8gMBgfIE8QMB84TxxPDE8ITyhMH
xwzbD8sMEAUMBcIMwgYH1RPKE8UTwxMT0RMH2wwGEAYQBhACBQwFDAUMBgwHBgfWE8sTxRPDExPu
EwYMBhAGEAIGDAYMwwYH1xPLE8YTwxMT8BPKBgfYE8wTxhPDExP1E9sTzRPHE8MTwhP1E9sTzRPH
E8MTwhMMAAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD/
/wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8A
AAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A
//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA/wAA
AP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCkgICA
/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vwoKCk
gICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw//vw
oKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzApsrw
//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDAwNzA
psrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICAwMDA
wNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACAAICA
wMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACAgACA
AICAwMDAwNzApsrw//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////AAAAgAAAAIAAgIAAAACA
gACA//vwoKCkgICA/wAAAP8A//8AAAD//wD/AP//////
--0__=jlQHYOlCtHXykdPJ3zxRY18455jmOLf8vKLRC2qyQSQi7OdjHHhD3pYO--