I will try to take a look this week and see what I can do. -Nathan ________________________________________ From: devel [devel-boun...@open-mpi.org] on behalf of George Bosilca [bosi...@icl.utk.edu] Sent: Thursday, August 07, 2014 10:37 PM To: Open MPI Developers Subject: Re: [OMPI devel] RFC: add atomic compare-and-swap that returns old value
Paul's tests identified an small issue with the previous patch (a real corner-case for ARM v5). The patch below is fixing all known issues. Btw, there is still room for volunteers for the .asm work. George. On Tue, Aug 5, 2014 at 2:23 PM, George Bosilca <bosi...@icl.utk.edu<mailto:bosi...@icl.utk.edu>> wrote: 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. On Aug 1, 2014, at 18:09 , Paul Hargrove <phhargr...@lbl.gov<mailto: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<mailto: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<mailto: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<mailto: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<mailto:phhargr...@lbl.gov>> wrote: >>> >>> On Tue, Jul 29, 2014 at 2:10 PM, Nathan Hjelm >>> <hje...@lanl.gov<mailto: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().
