[mpi3-coll] Non-blocking Collectives Proposal Draft

Graham, Richard L. rlgraham at ornl.gov
Fri Oct 17 04:57:16 CDT 2008

To me this does not look like a deadlock, proc o will make progress in the wait, and just like with point-to-point commuications process 1 will make general mpi progress while in the bcast.  This includes progress on the ibcast so that process 0 can comete it's ibcast and move on to the bcast.


----- Original Message -----
From: mpi3-coll-bounces at lists.mpi-forum.org <mpi3-coll-bounces at lists.mpi-forum.org>
To: MPI-3 Collective Subgroup Discussions <mpi3-coll at lists.mpi-forum.org>
Sent: Fri Oct 17 05:14:04 2008
Subject: Re: [mpi3-coll] Non-blocking Collectives Proposal Draft

Dear Torsten,

Thanks. I'm still unsure I understand how the example would work if
processes blocked in the Wait calls as you said below. In this case
process 0 would have no chance to reach the Bcast, while process 1 would
be inside it and never reached the Wait.

Here again is the original diagram:

Process 0			Process 1

MPI_Ibarrier(req)		MPI_Ibarrier(req)
MPI Bcast			MPI_Bcast*

The stars mark the point where the respective processes would block, as
far as I understand. Looks like deadlock?

Apart from this, stating that the nonblocking collectives can block in
Wait presumes a certain implementation. What if Ibarrier was able to do
all right away, and Wait were just a no-op?

I think mixing blocking and nonblocking collectives in the proposed way
should either be very carefully considered, or simply disallowed.

Best regards.


-----Original Message-----
From: mpi3-coll-bounces at lists.mpi-forum.org
[mailto:mpi3-coll-bounces at lists.mpi-forum.org] On Behalf Of Torsten
Sent: Thursday, October 16, 2008 11:15 PM
To: MPI-3 Collective Subgroup Discussions
Subject: Re: [mpi3-coll] Non-blocking Collectives Proposal Draft

Hello Alexander,

> Thank you. The pt2pt progress comment below was taken into account
> you removed the nonblocking collective progress description.
ah, ok - so I think a reference to the chapter should be sufficient.

> As for the example, if it is legal, we should probably count the
> blocking operations as well when we decide how many simultaneous ops
> to be supported.
yes, maybe. I am not sure but this could be an issue. It's on the agenda

> Why "if" above: I'm not sure what a delayed nonblocking barrier would
> mean for process 1. Won't one process possibly block somewhere? Can
> explain this please?
the barriers will only block in the respective MPI_Wait() (or a tight
MPI_Test() loop). But the operation can be initiated as soon as the
critical region is left (and there mihgt be some other independent
computation to do).

> The format matter is complicated. I think it is worth discussing at
> Forum as we're likely to have more and more proposals approaching the
> final stage, when editing them in PDF format will become an issue.
yes, it's on the WG agenda - maybe we should discuss this in the whole


 bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ -----
Torsten Hoefler       | Postdoctoral Researcher
Open Systems Lab      | Indiana University    
150 S. Woodlawn Ave.  | Bloomington, IN, 474045, USA
Lindley Hall Room 135 | +01 (812) 855-3608
mpi3-coll mailing list
mpi3-coll at lists.mpi-forum.org
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

mpi3-coll mailing list
mpi3-coll at lists.mpi-forum.org

More information about the mpiwg-coll mailing list