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.
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?
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.
devel mailing list
devel mailing list