Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 7 Jan 2014 07:50:30 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Oleg Bulyzhin <oleg@FreeBSD.org>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: atomic_load_acq @ i386/amd64
Message-ID:  <20140107055030.GJ59496@kib.kiev.ua>
In-Reply-To: <20140104232910.GA12331@lath.rinet.ru>
References:  <20140103205159.GA99722@lath.rinet.ru> <20140104172923.GY59496@kib.kiev.ua> <20140104232910.GA12331@lath.rinet.ru>

next in thread | previous in thread | raw e-mail | index | archive | help

--MEhAVL6rS7bF26GE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 05, 2014 at 03:29:10AM +0400, Oleg Bulyzhin wrote:
> On Sat, Jan 04, 2014 at 07:29:23PM +0200, Konstantin Belousov wrote:
> > On Sat, Jan 04, 2014 at 12:51:59AM +0400, Oleg Bulyzhin wrote:
> > >=20
> > > Hello.
> > >=20
> > > I've got a question: why atomic_load_acq_* implemented on i386/amd64 =
archs
> > > with locked cmpxchg instruction? Comment about this
> > > (in /sys/(amd64|i386)/include/atomic.h) looks wrong for me. I believe
> > > acquire/release semantics does not require StoreLoad barrier so simpl=
e aligned
> > > load should be enough. (because acquire/release semantics does not gu=
arantee
> > > sequential consistency).
> >=20
> > You did not explicitely wrote which statement in the comment is false, =
in
> > your opinion.
>=20
> >=20
> > FreeBSD assumes a property of _acq/_rel stuff which is sometimes called
> > 'total lock ordering'. It is indeed sort of sequential consistency, but
> > only for atomic+membar ops. Would atomic_load_acq()  implemented as pla=
in
> > load, it can pass stores, in particular stores from the _rel op, which
> > breaks the guarantee.
> >=20
> > For x86, there are indeed two possible schemes for implementing critical
> > section, one is lock cmpxchg for get(), and plain store for release(),
> > which is what we use. Another is plain load for get(), and xchg for
> > release().  Then, the load_acq() must be adopted to not break the acq/r=
el
> > consistency, and since we use plain store for release(), load_acq must
> > use serialing instruction.
>=20
> Perhaps i was not clear enough, i'm talking about this one:
> "However, loads may pass stores, so for atomic_load_acq we have to
>  ensure a Store/Load barrier to do the load in SMP kernels."
>=20
> As far as i know acquire/release semantics guarantees following:
> if we have this code
> <prev_code>
> _acq
> <some code>
> _rel
> <post_code>
>=20
> following statements are true:
> 1) <some code> cannot leave (due to reordering) acq/rel block
> 2) <prev_code> may leak past _acq=20
> 3) <post_code> may leak before _rel
> So neither _acq nor _rel requires full membar. I.e.
> op_acq is:
> <op>
> <one way membar, down->up reordering is prohibited>
> op_rel is:
> <one way membar, up->down reordering is prohibited>
> <op>
>=20
> Intel documentation says about only thing (for simple load/stores) can be
> reordered: "Reads may be reordered with older writes to different locatio=
ns
> but not with older writes to the same location."
>=20
> So, if older store can pass our load_acq() it would not break requirement=
s.
> And i do not understand how load op from load_acq() can pass store op from
> store_rel(), intel doc says: "Writes are not reordered with older reads".=
=20
Please re-read what I wrote above about 'total lock ordering'.

>=20
> Well, while writing this email i realized what is disturbing me: it's ato=
mic(9)
> "Multiple Processors" section. It claims atomics are not atomic in common=
 MP
> case and says atomics are atomic @i386. It looks strange for me:
> 1) i guess it's not "atomic" even for i386/MP without proper membar pairi=
ng.
> 2) if we have acq/rel modifiers for atomics why we cannot guarantee "atom=
icity"
>    for any MP arch?
>=20
> P.S. please correct me if i'm wrong in my statements, i'm spending my new=
 year
> holidays for ignorance elimination. ;)

I do not know what do you mean by 'not atomic'.

--MEhAVL6rS7bF26GE
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)

iQIcBAEBAgAGBQJSy5WlAAoJEJDCuSvBvK1B/r8P/i0sYZOX4UtHPAZ9/dU8KqBi
+nxMCdLFO3wlunp38okA2Osu0jg4zb8395FUbnXDKcUXg80EPGfRq62s39Pp45LS
0WJvmJXyxpSfugBELrS+wipPqFIcefshjVVSXVSxdZO+KYxM466JwtbwgVpFQQTI
Lt3QK/r8mNeueu7VlLHWWuTtNLkyaKSxu9x9fwek46ozeoB/wWvzjdoE6pDyDXDC
lDNHtqjNa897iIVrww/Wo56P4yi8yuGMdKdlBlhnNQDHQxTn+j5eJsPGkGTwPeDr
CjJ3hp3qi/1gm6xROAKSiBdLathhVaWl2kbxux6Xxm+7ExlOHyYslFL53TcU7NUl
s8wcIauRuDMtAJg8zWCAmailrk+VhJ6PVNmXwG5SYaLbx9g+KDIKXwVLkBVEaNj/
zj08GqvdimzF7LQAbPrx/7J1M2Dm2Z/Eb/eD+5YAt1YR53QdkW6yqIPou0QbEutv
rTXLCnWGpawQNAo5ys+OlKTH++ndqIr7q1XCjXns4to+V2+yMA+EvtpBaSeTapt5
/yJDln0YNlTlJkRtbdS+WH9XtE8dBEfFjzHEDNil7ErJjloXYBEqfoTiGfkz8o5g
ba6QXY3E9w4JZco70BgofP9+4S724VTEw3JIMcPe3xFtnPCoQMoiit4sR5nHxtI+
awJkRKHJpB//LIQAC4RW
=ZbcN
-----END PGP SIGNATURE-----

--MEhAVL6rS7bF26GE--



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