From: Andres Freund <andres@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Geoghegan <pg@heroku.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Cc: Ants Aasma <ants@cybertec.at>
Subject: Re: better atomics - v0.5
Date: Thu, 26 Jun 2014 13:21:48 +0200
Message-ID: <20140626112148.GC1926@awork2.anarazel.de> (raw)
In-Reply-To: <CA+Tgmobr+0aak5_6kQwsYfuKGs0JhTy7VQ7tn_rNtF205YSZ2g@mail.gmail.com>
References: <CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com>
<20140625171434.GG24114@awork2.anarazel.de>
<CA+TgmoZShVVqjaKUL6P3kDvZVPibtgkzoti3M+Fvvjg5V+XJ0A@mail.gmail.com>
<20140625203635.GJ24114@awork2.anarazel.de>
<53AB424D.8030306@vmware.com>
<CA+Tgmobr+0aak5_6kQwsYfuKGs0JhTy7VQ7tn_rNtF205YSZ2g@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 2014-06-25 20:22:31 -0400, Robert Haas wrote:
> On Wed, Jun 25, 2014 at 5:42 PM, Heikki Linnakangas
> <hlinnakangas@vmware.com> wrote:
> > I think having a separate file for each architecture is nice. I totally
> > agree that they don't belong in src/include/storage, though. s_lock.h has
> > always been misplaced there, but we've let it be for historical reasons, but
> > now that we're adding a dozen new files, it's time to move them out.
>
> I find the current organization pretty confusing, but maybe that could
> be solved by better documentation of what's supposed to go in each
> architecture or compiler-dependent file.
The idea is that first a architecture specific file (atomics-arch-*.h)
is included. That file can provide a (partial) implementation for the
specific architecture. Or it can do pretty much nothing.
After that a compiler specific file is included
(atomics-generic-*.h). If atomics aren't yet implemented that can
provide an intrinsics based implementation if the compiler version has
support for it. At the very least a compiler barrier should be provided.
After that the spinlock based fallback implementation
(atomics-fallback.h) provides atomics and barriers if not yet
available. By here we're sure that nothing else will provide them.
Then we can provide operations (atomics-generic.h) that build ontop of
the provided functions. E.g. implement _sub, _and et al.
I'll include some more of that explanation in the header.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: andres@2ndquadrant.com, robertmhaas@gmail.com, hlinnakangas@vmware.com, tgl@sss.pgh.pa.us, pg@heroku.com, ants@cybertec.at
Subject: Re: better atomics - v0.5
In-Reply-To: <20140626112148.GC1926@awork2.anarazel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox