Re: [Xen-devel] read_atomic, write_atomic, add_sized

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.06.17 at 15:02, <julien.grall@xxxxxxx> wrote:
> On 13/06/17 13:48, Jan Beulich wrote:
>>>>> On 13.06.17 at 11:42, <julien.grall@xxxxxxx> wrote:
>>> Looking at the usage on Linux, many places is using
>>> ACCESS_ONCE/WRITE_ONCE/READ_ONCE assume this will be done in a single
>>> instructions (see atomic_read/atomic_write on both x86 and ARM).
>>>
>>> My understanding is, at least on ARM GCC (?), assignment will be atomic
>>> (though will not prevent the compiler to only write/read once). We make
>>> this assumption in quite a few places (such as PV protocol for the
>>> index) and I am not sure to understand why it cannot be done in other
>>> places...
>>
>> To a certain degree we can / want to assume compilers don't do
>> insane things. I.e. why would they commonly emit multiple insns
>> if a single suffices. However, we would better write our code
>> such that we don't _depend_ on this, the more that I've explained
>> (or was that on a different thread) that e.g. read-modify-write
>> operations on memory operands commonly get carried out by the
>> compiler by 3 insns even though most of the time it could be done
>> by just one.
> 
> That's from an x86 POV. ARM (at least until ARMv8.0) does not have 
> read-modify-write operations. If the compiler is not using them on x86 
> then maybe you should look at fixing that in the compiler?
> 
> However, looking at the patch that introduced add_sized, the intention 
> was not about preventing the compiler to use 3 insns:

Sure - I've only given this as an example to demonstrate that we
can't always assume the compiler does exactly what we want it to.

>> And then, as the cited code still visible above shows, atomicity is
>> not going to be guaranteed for most of the access sizes anyway.
>> How can you imply that the given constructs are safe to use as
>> atomic accesses for some variables, but not for others? Such a
>> property ought to be universal (and the build should fail if it is
>> being violated). Otherwise a simple type change of some
>> variable may render the code buggy possibly without anyone
>> noticing.
> 
> It is a choice from Linux side to allow using READ_ONCE/WRITE_ONCE with 
> bigger size. I am not suggesting to do the same on Xen but avoiding the 
> bigger size.

But Andre had raised that very question.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel