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? George. On Oct 8, 2013, at 18:14 , Ralph Castain <r...@open-mpi.org> 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 > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
