Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value

[George Bosilca]

Thanks to Paul help all the inlined atomics have been tested. The new patch is attached below. However, this only fixes the inline atomics, all those generated from the *.asm files have not been updated. Any volunteer?   George.

atomics.patch
Description: Binary data

On Aug 1, 2014, at 18:09 , Paul Hargrove <phhargr...@lbl.gov> wrote: I have confirmed that George's latest version works on both SPARC ABIs. ARMv7 and three MIPS ABIs still pending... -Paul On Fri, Aug 1, 2014 at 9:40 AM, George Bosilca <bosi...@icl.utk.edu> wrote: 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 <bosi...@icl.utk.edu> 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 <hje...@lanl.gov> 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 <phhargr...@lbl.gov> wrote: >>> >>>    On Tue, Jul 29, 2014 at 2:10 PM, Nathan Hjelm <hje...@lanl.gov> 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                          phhargr...@lbl.gov >>>    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 >>>    de...@open-mpi.org >>>    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 >>> de...@open-mpi.org >>> 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 >> de...@open-mpi.org >> 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 > _______________________________________________ devel mailing list de...@open-mpi.org Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel Link to this post: http://www.open-mpi.org/community/lists/devel/2014/08/15462.php --  Paul H. Hargrove                          phhargr...@lbl.gov 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 de...@open-mpi.org Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel Link to this post: http://www.open-mpi.org/community/lists/devel/2014/08/15465.php