From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 7 05:50:35 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BDD49891; Tue, 7 Jan 2014 05:50:35 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 429E11328; Tue, 7 Jan 2014 05:50:35 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id s075oUX9062545; Tue, 7 Jan 2014 07:50:30 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s075oUX9062545 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id s075oUd1062544; Tue, 7 Jan 2014 07:50:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 7 Jan 2014 07:50:30 +0200 From: Konstantin Belousov To: Oleg Bulyzhin Subject: Re: atomic_load_acq @ i386/amd64 Message-ID: <20140107055030.GJ59496@kib.kiev.ua> References: <20140103205159.GA99722@lath.rinet.ru> <20140104172923.GY59496@kib.kiev.ua> <20140104232910.GA12331@lath.rinet.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MEhAVL6rS7bF26GE" Content-Disposition: inline In-Reply-To: <20140104232910.GA12331@lath.rinet.ru> User-Agent: Mutt/1.5.22 (2013-10-16) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 05:50:35 -0000 --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 > > _acq > > _rel > >=20 > following statements are true: > 1) cannot leave (due to reordering) acq/rel block > 2) may leak past _acq=20 > 3) may leak before _rel > So neither _acq nor _rel requires full membar. I.e. > op_acq is: > > up reordering is prohibited> > op_rel is: > down reordering is prohibited> > >=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--