svn commit: r324926 - head/share/man/man9

[Konstantin Belousov]

On Mon, Oct 23, 2017 at 10:28:22AM -0600, Ian Lepore wrote:
> On Mon, 2017-10-23 at 16:14 +0000, Konstantin Belousov wrote:
> > Author: kib
> > Date: Mon Oct 23 16:14:55 2017
> > New Revision: 324926
> > URL: https://svnweb.freebsd.org/changeset/base/324926
> > 
> > Log:
> >   Expand explanation of atomicity.
> >   
> >   Mention per-location total order, out of thin air, and torn writes
> >   guarantees.  Mention C11 standard' memory model and one most important
> >   FreeBSD additional requirement, that is aligned ordinary loads and
> >   stores are atomic on processors.
> >   
> > [...]
> > 
> > +On all architectures supported by
> > +.Fx ,
> > +ordinary loads and stores of naturally aligned integer types
> > +are atomic, as executed by the processor.
> 
> This is not true on arm{v6,v7}.  64-bit integer types can be atomically
> loaded and stored with the appropriate functions from atomic.h, but are
> not ordinarily so, regardless of alignment.  Smaller integer types do
> meet this requirement.

You cannot load 64bit integer on ARM at all, because there is no 64bit GPRs.
The LDRD and LDM instructions just reinforce the point.  Same is true for
all other 32bit arches.

But perhaps you are right, mentioning the 'native size' there would be
useful.

Note that the statement contains the appendix 'as executed by processor'.  
For instance, there is nothing that would prevent compiler from splitting
the access, either explicitly or by executing memcpy() instead of LDR/STR.
I thought that this would provide big enough hint to not talk about
native integers size.