Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] opal_init/finalize counter --> boolean
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2011-07-11 10:01:46

On Jul 11, 2011, at 7:28 AM, George Bosilca wrote:

>> How about a compromise?
> Based on the english dictionary a compromise is an agreement or a settlement of a dispute that is reached by each side making concessions. This is not a compromise. This is exactly what Ralph did plus name changes. Therefore, this is a single sided settlement.

Actually, it gives you what you wanted, too (i.e., the ability to separately init/finalize OPAL util vs. the rest of OPAL).

Hence, it's a compromise.

>> - Take what is (essentially) in opal_init() today and rename it to be opal_init_frameworks() -- because it's (mostly) initializing the OPAL MCA frameworks.
>> - Take what is (essentially) in opal_finalize() today and rename it to be opal_finalize_frameworks() -- because it's (mostly) finalizing the OPAL MCA frameworks. Remove the call to opal_finalize_util() from this function.
>> - Remove all use of counters; calling opal_init*() will initialize (unless it has already been initialized), and calling opal_finalize*() will finalize (unless it has already been finalized).
>> - Create a new opal_init() function that is a wrapper around opal_init_util() and opal_init_frameworks(). Create a new opal_finalize() function that is a wrapper around opal_finalize_util() and opal_finalize_frameworks().
>> - orte_finalize() will call opal_finalize() -- i.e., it will unconditionally shut down all of OPAL. This will remove the need for opal_finalize_util() in the MPI layer.
>> This seems to give all desired behaviors:
>> - All <foo>_finalize() functions will be unconditional. The Law of Least Surprise is preserved.
>> - There are paths for split init and split finalize and combined init and combined finalize. They can even be combined (e.g., split init and combined finalize -- which will be a common case, actually).
> Least surprise you say? How surprise one will be once he/she realize that orte_finalize teared down all OPAL. At least, do not forget to add one of those nice comments about the fact that one have to initialize the utils, but don't have to finalize them, ORTE will graciously do it for you.

To clarify: you can *choose* to separately initialize the OPAL utilities if you want/need to.

Otherwise, the lower layer -- ORTE -- will both initialize and finalize OPAL for you. Isn't that what lower layers are supposed to do?

OPAL has a weird "side entrance" because we need to use some of OPAL (MCA params) before the rest of the system. *That's* the weird part. We actually somewhat violate abstraction barriers there, IMHO (but I don't know any way around that).

> You want to change names, OK go for it. At the point where the code is today, I don't think it really matters anymore. In fact why do we need a boolean in the code Ralph put inside? If the opal_finalize is supposed to clean up everything just go ahead and remove that useless bool. And as you made the code easy to understand by few, put a big comment for all the others

Do you really find this confusing?

int opal_finalize(void)
    if (!opal_initialized) {
        return OPAL_SUCCESS;

FWIW, we have similar patterns elsewhere in OMPI for preventing multiple initializations / finalizations. Are you saying that we should remove all of those, too?

> (the ones that will try to understand why their code break after a simple orte_finalize).

Can you cite any codes that will break if OPAL is finalized during orte_finalize()? I thought you said in a prior mail on this thread that no one uses OPAL after orte_finalize() anyway -- we *might* want to in the future, but no one does it today. Am I remembering incorrectly?

Jeff Squyres
For corporate legal information go to: