On 8/11/11, Andrew MacLeod <amacl...@redhat.com> wrote:
> The __sync_mem_fetch_{add,sub,and,xor,or} routines perform the operation
> atomically, and return the value that was in memory before the operation
> was performed.  As I was working on switching the c++ wrappers to use
> these new routines, I discovered we also need the versions which return
> the *result* of the operation atomically.

You don't need "after" routines for C++, all the operations can be
implemented on top of "before" routines.

int add_after(atomic<int>& ai, int i) {
    return add_before(ai, i) + i;
}

> I implemented them initially to add a flag to indicate whether we wanted
> the value before or after the operation, but in actual practice it was a
> bit awkward to use and I was not happy with it. Instead, I simply reused
> as much internal code as I could, and added new __sync routines.
>
> The names for the previous set implies the fetch is done before the
> operation, so the new ones simply drop the fetch and simply use the
> operation name. I found sync_mem_op_fetch slightly less clear.  the new
> routines documentation looks like:
>
>     TYPE __sync_mem_add (TYPE *ptr, TYPE val, int memmodel)
>     TYPE __sync_mem_sub (TYPE *ptr, TYPE val, int memmodel)
>     TYPE __sync_mem_and (TYPE *ptr, TYPE val, int memmodel)
>     TYPE __sync_mem_xor (TYPE *ptr, TYPE val, int memmodel)
>     TYPE __sync_mem_or (TYPE *ptr, TYPE val, int memmodel)
>           These builtins perform the operation suggested by the name, and
>           return the result of the operation. That is,
>
>                { *ptr OP= val; return *ptr; }
>
>           All memory models are valid.
>
> I also decided to change the testcases around (again).  I merged all the
> different fetch_op tests into one, and added all the new tests.  now
> there is simply 5 tests files sync-mem-op-[1-5].c to test all these
> routines for (1)char, (2)short, (3)int, (4)long long, and (5)__int128_t.
>
> Bootstrapped and no new regressions on x86-64.  (I am re-verifying
> overnight however).  OK for the branch?
>
> Andrew
>
>


-- 
Lawrence Crowl

Reply via email to