1) MPI_Get_counter(comm,count): no change. This is analogous
to MPI_Probe. (MPI1 also has MPI_Iprobe. I see no use for
MPI_Iget_counter since Get_counter will return promptly even when
the counter is found to be zero.)
2) MPI_Consume_counter(comm,count): this blocks until counter>=count,
decrements counter by count and returns. This is analogous to
MPI_Recv. It would often be used with the info obtained by MPI_Get_count
and in this case would return promptly. (Much like doing an MPI_Probe
followed by an MPI_Recv that uses the output of MPI_Probe.)
3) MPI_Iconsume_counter(comm,count,request): this returns a request
which can be tested or waited. This is analogous to MPI_Irecv.
Depending on what happens with handlers, it could also have a
handler posted. This is essentially MPI_Set_counter_threshold
with a different name.
I am not clear on why we would need to say that two MPI_Iconsume_counter
postings against the same counter are forbidden. I see no problem
with allowing more than one and simply saying that if one has
a smaller count than another, it will complete first. If two
or more have the same count, they will complete in the order posted.
The MPI_Iconsume_counter implies that a request returned by a call to
it could be canceled. MPI_Set_counter_threshold does not say explicitly
but I presume a request from it would also be cancelable (yes?)
Dick Treumann
Dick Treumann POWER Parallel Systems
(Internet) treumann@kgn.ibm.com IBM -- Poughkeepsie, NY
(VNET) TREUMANN at KGNVMC Tel: (914) 433-7846
(internal) treumann@windsurf.kgn.ibm.com Fax: (914) 433-8363