IIRC, the concern was with where the thread safety should reside. Some classes (e.g., opal_list) were littered with thread locks for every operation. So if someone implemented thread protection at a higher level (e.g., protecting the list while cycling thru it), then all these lower-level lock/unlock operations were just a waste of cycles.
However, some people felt that there were places where it helped to have the locking down below. So this was the compromise - use the version that fits your situation. Personally, I'm not wild about it, but I can live with it. I'd prefer to see no lock/unlock calls in the classes themselves as they are too atomistic, and would have opted for providing a macro version of the function that included the appropriate lock/unlocks around the function. Anyway, that was the thinking at the meeting last June. On Oct 9, 2013, at 1:40 AM, George Bosilca <bosi...@icl.utk.edu> wrote: > 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 > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
