Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M253639=pgsql-hackers-arkari@postgresql.org>)
 id 1X5gw4-0004Hx-0c
 for pgsql-hackers@arkaria.postgresql.org; Fri, 11 Jul 2014 19:56:48 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M253639=pgsql-hackers-arkari@postgresql.org>)
 id 1X5gw3-0004VE-G0
 for pgsql-hackers@arkaria.postgresql.org; Fri, 11 Jul 2014 19:56:47 +0000
Received: from makus.postgresql.org ([2001:4800:1501:1::229])
 by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
 (Exim 4.80) (envelope-from <kleptog@svana.org>) id 1X5gw1-0004V5-ST
 for pgsql-hackers@postgresql.org; Fri, 11 Jul 2014 19:56:46 +0000
Received: from bilbys.org ([2400:c400::113:212:99:188] helo=svana.org)
 by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.80) (envelope-from <kleptog@svana.org>) id 1X5gvy-0007M5-33
 for pgsql-hackers@postgresql.org; Fri, 11 Jul 2014 19:56:44 +0000
Received: from kleptog by svana.org with local (Exim 4.72)
 (envelope-from <kleptog@svana.org>)
 id 1X5gvc-0004Ut-4g; Sat, 12 Jul 2014 05:56:22 +1000
Date: Fri, 11 Jul 2014 21:56:20 +0200
From: Martijn van Oosterhout <kleptog@svana.org>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
 Andres Freund <andres@2ndquadrant.com>,
 Tom Lane <tgl@sss.pgh.pa.us>, Peter Geoghegan <pg@heroku.com>,
 Pg Hackers <pgsql-hackers@postgresql.org>, Ants Aasma <ants@cybertec.at>
Message-ID: <20140711195619.GA22880@svana.org>
Reply-To: Martijn van Oosterhout <kleptog@svana.org>
References: 
 <CAA4eK1+j2xp-xGLh2M8xATnv_X=0j1678Pw-wuGy1O8Kw-qWnw@mail.gmail.com>
 <20140629092421.GH6450@awork2.anarazel.de>
 <CAA4eK1JqqqZuqvKzfUB-XX381xxfGYHSCVmtYA307GKf5X1uyQ@mail.gmail.com>
 <20140630092401.GJ21422@awork2.anarazel.de>
 <CAA4eK1Jygpgm-uCz4Hj+wQ8mfPP6rJ102326H5=OMgzfpktgoA@mail.gmail.com>
 <20140701104058.GZ26930@awork2.anarazel.de>
 <CAA4eK1KsUMTErTDf-ht3-Qb7NvkVPGd-=Uy7NrEi2oviJgk9tA@mail.gmail.com>
 <CAA4eK1J9EAn7U5pH0587WmBKceLNzq9jKTZWEY74HBTT4bfq+g@mail.gmail.com>
 <CA+TgmoZCQD50m82NgTeYEr+iSoWdK7_5di8+E8ph67yG4iw9Tw@mail.gmail.com>
 <CAA4eK1LSzPPiBfJVPC2dLuuvgdgz2sWO_pBwpdkgC=75OP2XeA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24"
Content-Disposition: inline
In-Reply-To: 
 <CAA4eK1LSzPPiBfJVPC2dLuuvgdgz2sWO_pBwpdkgC=75OP2XeA@mail.gmail.com>
X-PGP-Key-ID: Length=4096; ID=0x4BE62D44
X-PGP-Key-Fingerprint: AF6F C0D6 3B8A AF7D 942B  D2BC 4BED FBE7 4BE6 2D44
User-Agent: Mutt/1.5.20 (2009-06-14)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: kleptog@svana.org
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on calyx
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NO_RELAYS
 autolearn=ham version=3.3.1
Subject: Re: better atomics - v0.5
X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:26:47 +0000)
X-SA-Exim-Scanned: Yes (on svana.org)
X-Pg-Spam-Score: -1.9 (-)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


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

On Thu, Jul 10, 2014 at 08:46:55AM +0530, Amit Kapila wrote:
> As per my understanding of the general theory around barriers,
> read and write are defined to avoid reordering due to compiler and
> full memory barriers are defined to avoid reordering due to processors.
> There are some processors that support instructions for memory
> barriers with acquire, release and fence semantics.

Not exactly, both compilers and processors can rearrange loads and
stores.  Because the architecture most developers work on (x86) has
such a strong memory model (it's goes to lot of effort to hide
reordering) people are under the impression that it's only the compiler
you need to worry about, but that's not true for any other
architechture.

Memory barriers/fences are on the whole discouraged if you can use
acquire/release semantics because the latter are faster and much easier
to optimise for.

I strongly recommend the "Atomic Weapons" talk on the C11 memory model
to help understand how they work. As a bonus it includes correct
implementations for the major architectures.

Have a nice day,
--=20
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts.
   -- Arthur Schopenhauer

--u3/rZRmxL6MmkK24
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIVAwUBU8BBY0vt++dL5i1EAQj5xA/+NOKkgq+zGeoWwyfvUaeYJvFRCKbjHwHF
dIT26EcQ1+HUL7aZzN+87Ng+FucRBsbF/Xt7RJ436H5WNVbs/BP//0v/WEhGk8Hm
dPQqCDdjVOqHwqXahTNbfj5kZfQ0Nv5nv+DTQioVbyft0KZCVuLb6gjb92YjqrL7
GKFqyHs2SDeN0BkBdK0DmipjZXonTOHMI7vklPYUoG0wnXZ2QyFlYk4Yjcb9XMP1
G+/AYkdWdtpgMYiF6mfzY5XDJTuHKU6t2nbg4FIKt99shwlUxWa4ajCg/D6TGqwL
DHiB/TSup7QbXZhw3cPDkvH6cogFWVWsg6hyNZLgCAKFkB0Gz/lLWNI+qyzWJUPF
2Qj5IFQf1n+cz6TlwLaVdVwcqUHqq22Cmj4suLH6Ly8cu3Adn3KjTsZp/ZSP7sNL
fY5XG4B2HBqFpUb73ALS/A5W5o4kZQ9HtrV7sRe1ezGkM0QUTIH0Sz/OcCc7PBU+
Sl8bNRWGSYtvIGaTgZ3j4jHPP4EKvYbytpY1EkE4Dq7XDl+BlVCH9VquvzQOs2nk
hg8FUloa5+zo/x4NcIeZJ3LQRXVE7EkPSg/KW6a7ou4TdEGA2thVX907D2mfP1dq
lemC7VoMQVUrX/wHDbxiiTD12kxttQVZbVXzuzQUcjiw1vv88GaKqCqy5PBlg2ZH
abWoG4wFjXw=
=WtVn
-----END PGP SIGNATURE-----

--u3/rZRmxL6MmkK24--