Re: [Xen-devel] [RFC PATCH] docs: add README.atomic

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Stefano Stabellini <sstabellini@xxxxxxxxxx> 06/15/17 2:27 AM >>>
>On Wed, 14 Jun 2017, Jan Beulich wrote:
>> >>> Stefano Stabellini <sstabellini@xxxxxxxxxx> 06/14/17 8:45 PM >>>
>> >On Wed, 14 Jun 2017, Jan Beulich wrote:
>> >> > +What ACCESS_ONCE does *not* guarantee though is this access is done in 
>> >> > a
>> >> > +single instruction, so complex or non-native or unaligned data types 
>> >> > are
>> >> > +not guaranteed to be atomic. If for instance counter would be a 64-bit 
>> >> > value
>> >> > +on a 32-bit system, the compiler would probably generate two load 
>> >> > instructions,
>> >> > +which could end up in reading a wrong value if some other CPU changes 
>> >> > the other
>> >> > +half of the variable in between those two reads.
>> >> > +However accessing _aligned and native_ data types is guaranteed to be 
>> >> > atomic
>> >> > +in the architectures supported by Xen, so ACCESS_ONCE is safe to use 
>> >> > when
>> >> > +these conditions are met.
>> >> 
>> >> As mentioned before, such a guarantee does not exist. Please only
>> >> state what is really the case, i.e. we _expect_ compilers to behave
>> >> this way.
>> >
>> >Regarding compilers support: do we state clearly in any docs or website
>> >what are the compilers we actually support? I think this would be the
>> >right opportunity to do it.
>> 
>> At the very least we state somewhere what gcc versions we support. However,
>> I can't see the relation of such a statement to the discussion here.
>
>The relation is that our "compiler expectations" shape what compilers we
>support.

I don't view it this way - we implicitly support unknown future versions of gcc,
and we can't know if they might break our assumptions.

Jan



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