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>