[Mpi3-hybridpm] First cut at slides

[Jeff Squyres (jsquyres)]

On Jun 22, 2013, at 9:30 AM, Pavan Balaji <balaji at mcs.anl.gov> wrote:

>> I guess my point is that process A must wait for the *actual*
>> finalization in process B (which is the 2nd one), and if Finalize
>> synchronizes (which most.. but not all.. MPI implementations do),
>> then A will block until B calls the 2nd Finalize.
> 
> Eh?  My reading was that they *might* synchronize on every FINALIZE call, but will *finalize* only when ref-count is zero.

Yes, that is definitely possible (since "collective" *might* mean synchronize).

But I gave this some more thought over the weekend, and I'm now even more uncomfortable with it: in my example, process A calls FINALIZE once, and that's when it actually finalizes process A.  It's collective with the *first* call to FINALIZE on proc B, which *doesn't* finalize process B.  

So yes, A/FINALIZE *might* synch with B/first FINALIZE -- but that's not really the point.  A also has the added requirement that it needs to *actually finalize* A.  And it therefore needs to synchronize with B/second FINALIZE, for which it was *not* explicitly paired via a collective operation.

Put differently: A's FINALIZE is collective with B/first FINALIZE (by definition), but in practice it may need to synchronize with B/second FINALIZE.

That's just weird.

>> But I think I'm coming to the conclusion that if you want to not be
>> affected by Finalize-possibly-blocking semantics, then you should
>> just call MPI_COMM_DISCONNECT first.
> 
> I don't think so.

What do you mean?

-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/