On Jun 22, 2013, at 9:30 AM, Pavan Balaji <[email protected]> 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 [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/