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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Thu, 15 Jun 2017, Jan Beulich wrote:
> >>> 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.

OK. In that case, in the same document or wikipage where we write about
gcc versions, it makes sense to write about compiler
assumptions/expectations too.

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