On Oct 11, 2013, at 17:09 , Ralph Castain wrote:
>
> On Oct 11, 2013, at 4:07 AM, George Bosilca wrote:
>
>>
>> On Oct 9, 2013, at 15:29 , Ralph Castain wrote:
>>
>>> IIRC, the concern was with where the thread safety should reside. Some
>>> classes (e.g., opal_list) were littered with th
On Oct 11, 2013, at 4:07 AM, George Bosilca wrote:
>
> On Oct 9, 2013, at 15:29 , Ralph Castain wrote:
>
>> 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 t
On Oct 9, 2013, at 15:29 , Ralph Castain wrote:
> 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 lis
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/u
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
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 th
