Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] Changes to classes in OMPI
From: George Bosilca (bosilca_at_[hidden])
Date: 2013-10-09 04:40:04

My concern is that increasing the number of interfaces will not make the code thread safe, as in most cases thread safety is not only a matter of using a _mt version of the basic class object but a matter of a careful manipulation of higher level concepts.

We can hardly use the lack of the _MT function as a reason for not having thread safety in the code. We did have the thread safety a while back without the support of _MT version of all the basic classes.

So I really wonder what is the rationale behind such an intrusive change of the codebase?


On Oct 8, 2013, at 18:14 , Ralph Castain <rhc_at_[hidden]> wrote:

> Hi folks
> This was one item from the last devel meeting that can be done independent of other things:
> • resolution: all opal and orte (and possibly ompi) classes need to have a thread safe and thread-free interface
> • _st suffix: single thread (i.e., not thread safe variant)
> • _mt suffix: multi thread (i.e., thread safe variant)
> • for functions that have both st/mt, they will *both* have suffixes
> • other functions (that do not have st/mt versions) will be naked names
> • need to rename all classes that have locking enabled already (e.g., opal_free_list)
> • so today, we go rename all the functions (e.g., opal_free_list functions get _mt suffix) throughout the code base
> • as someone needs the _st version, they go create it and use it as they want to
> • Ralph will do the orte classes
> • Aurelien will do this for the ompi classes
> I believe some of these have been done - I will take care of the ORTE classes this week, so consider this a "heads up" for that change.
> Ralph
> _______________________________________________
> devel mailing list
> devel_at_[hidden]