Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 23 Oct 2017 19:40:51 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Ian Lepore <ian@freebsd.org>
Cc:        Konstantin Belousov <kib@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r324926 - head/share/man/man9
Message-ID:  <20171023164051.GP2473@kib.kiev.ua>
In-Reply-To: <1508776102.34364.7.camel@freebsd.org>
References:  <201710231614.v9NGEtuP036360@repo.freebsd.org> <1508776102.34364.7.camel@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171023164051.GP2473>