Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value
From: George Bosilca (bosilca_at_[hidden])
Date: 2014-08-01 12:40:49


Another version of the atomic patch. Paul has tested it on a bunch of platforms. At this point we have confirmation from all architectures except SPARC (v8+ and v9).

  George.


On Jul 31, 2014, at 19:13 , George Bosilca <bosilca_at_[hidden]> wrote:

> All,
>
> Here is the patch that change the meaning of the atomics to make them always return the previous value (similar to sync_fetch_and_<*>). I tested this with the following atomics: OS X, gcc style intrinsics and AMD64.
>
> I did not change the base assembly files used when GCC style assembly operations are not supported. If someone feels like fixing them, feel free.
>
> Paul, I know you have a pretty diverse range computers. Can you try to compile and run a “make check” with the following patch?
>
> George.
>
> <atomics.patch>
>
> On Jul 30, 2014, at 15:21 , Nathan Hjelm <hjelmn_at_[hidden]> wrote:
>
>>
>> That is what I would prefer. I was trying to not disturb things too
>> much :). Please bring the changes over!
>>
>> -Nathan
>>
>> On Wed, Jul 30, 2014 at 03:18:44PM -0400, George Bosilca wrote:
>>> Why do you want to add new versions? This will lead to having two, almost
>>> identical, sets of atomics that are conceptually equivalent but different
>>> in terms of code. And we will have to maintained both!
>>> I did a similar change in a fork of OPAL in another project but instead of
>>> adding another flavor of atomics, I completely replaced the available ones
>>> with a set returning the old value. I can bring the code over.
>>> George.
>>>
>>> On Tue, Jul 29, 2014 at 5:29 PM, Paul Hargrove <phhargrove_at_[hidden]> wrote:
>>>
>>> On Tue, Jul 29, 2014 at 2:10 PM, Nathan Hjelm <hjelmn_at_[hidden]> wrote:
>>>
>>> Is there a reason why the
>>> current implementations of opal atomics (add, cmpset) do not return
>>> the
>>> old value?
>>>
>>> Because some CPUs don't implement such an atomic instruction?
>>>
>>> On any CPU one *can* certainly synthesize the desired operation with an
>>> added read before the compare-and-swap to return a value that was
>>> present at some time before a failed cmpset. That is almost certainly
>>> sufficient for your purposes. However, the added load makes it
>>> (marginally) more expensive on some CPUs that only have the native
>>> equivalent of gcc's __sync_bool_compare_and_swap().
>>>
>>> -Paul
>>> --
>>> Paul H. Hargrove PHHargrove_at_[hidden]
>>> Future Technologies Group
>>> Computer and Data Sciences Department Tel: +1-510-495-2352
>>> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>>> _______________________________________________
>>> devel mailing list
>>> devel_at_[hidden]
>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>> Link to this post:
>>> http://www.open-mpi.org/community/lists/devel/2014/07/15328.php
>>
>>> _______________________________________________
>>> devel mailing list
>>> devel_at_[hidden]
>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>> Link to this post: http://www.open-mpi.org/community/lists/devel/2014/07/15369.php
>>
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: http://www.open-mpi.org/community/lists/devel/2014/07/15370.php
>