Indeed. The lists you pinpoint at are used via the OMPI_FREE_LIST_GET macro, which is based on atomic operations. We're all safe on that front.
Even if multiple threads call the self BTL functions simultaneously we are safe due to the MPI semantics (the matching logic is protected, it can succeed only for one thread).
On Feb 8, 2012, at 21:38 , Christopher Yeoh wrote:
> On Wed, 8 Feb 2012 20:58:52 -0500
> George Bosilca <bosilca_at_[hidden]> wrote:
>> The self BTL is different from any other BTL. Any memcpy operation
>> done by this BTL is automatically protected behind the matching
>> logic, and therefore does not require extra thread safety protection.
>> A mutex in the self BTL is mostly a copy/paste mistake.
> So just to clarify, you don't just mean the data source and
> destination memory being protected by the matching logic, but
> also various linked lists such as self_frags_[eager|send|rdma]
> are implicitly protected?
> ie. Pretty much need an implicit guarantee that only one thread at a
> time will ever call the btl self functions which manipulate those lists.
>> On Feb 8, 2012, at 17:57 , Christopher Yeoh wrote:
>>> I've noticed that the self btl does not do any locking. It has one
>>> lock defined but its not actually used anywhere.
>>> So I'm just wondering if that is an oversight or if there is a
>>> reason that we know for sure that there will never be concurrent
>>> access to that particular btl with threads enabled?
>>> devel mailing list
>> devel mailing list
> devel mailing list