Re: [boost] [atomic] Generalized read-modify-write operation

Subject: Re: [boost] [atomic] Generalized read-modify-write operation
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-09-01 20:11:48

On 02.09.2015 02:20, Gavin Lambert wrote:
> On 1/09/2015 21:35, Andrey Semashev wrote:
>> I was wondering is there would be interest in a generalized
>> read-modify-write operation in Boost.Atomic. The idea is to have a
>> atomic<T>::read_modify_write method that would take a function that
>> would perform the modify on the atomic value. The interface could be
>> roughly this:
> [...]
>> Does this look interesting to anyone? Comments?
>
> It's not strictly necessary since it's equivalent to a do { r =
> modify(n); } while (!var.compare_exchange_weak(n, r, order)) loop, which
> isn't that much more typing. (Although I elided the initial load, so
> it's a bit more typing than it appears here.)

Yes, correct. r and n also have to be declared outside the loop, which 
is kind of annoying.

> (And the above is also supposed to use LL/SC on architectures where this
> is cheaper than CAS, although I'm not sure if this is the case.)

I'm not sure there are architectures that implement both CAS and LL/SC 
instructions, at least I'm not aware of such. On the architectures that 
support LL/SC, the instructions will be used to implement 
compare_exchange_weak. The modify function in this CAS loop will not be 
executed within the LL/SC region, which is why the additional load 
before the loop is required. There is also a probability of CAS failure.

There is another point to consider. compare_exchange_weak/strong 
opereation on an LL/SC architecure is more complex than what is required 
to implement a simple RMW operation. For example, let's see it in 
Boost.Atomic code for ARM. Here is fetch_add, which can be used as a 
prototype of what could be done with a generic RMW operation:

   "1:\n"
   "ldrex   %[original], %[storage]\n"
   "add     %[result], %[original], %[value]\n" // modify
   "strex   %[tmp], %[result], %[storage]\n"
   "teq     %[tmp], #0\n"
   "bne     1b\n"

Frankly, I'd like to be able to generate code like this for operations 
other than those defined by the standard atomic<> interface.

And here is CAS (weak):

   "mov %[success], #0\n"
   "ldrex %[original], %[storage]\n"
   "cmp %[original], %[expected]\n"
   "itt eq\n"
   "strexeq %[success], %[desired], %[storage]\n"
   "eoreq %[success], %[success], #1\n"

To this we will also have to add the load, the modify and the loop.

> But provided that the code generated is no worse than this (in
> particular that the compiler can inline the function call in optimised
> builds, at least where the function is relatively simple) then it would
> still be useful, particularly for people who aren't used to using weak
> exchange loops.

I certainly hope the compiler will be able to inline the modify 
function. If it doesn't, for relatively simple functions, then it 
probably isn't worth it.