From: Andres Freund <andres@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.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
Date: Wed, 16 Oct 2013 21:45:41 +0200
Message-ID: <20131016194541.GO5319@awork2.anarazel.de> (raw)
In-Reply-To: <CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com>
References: <CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 2013-10-16 14:30:34 -0400, Robert Haas wrote:
> > But _and, _or are really useful because they can be used to atomically
> > clear and set flag bits.
>
> Until we have some concrete application that requires this
> functionality for adequate performance, I'd be inclined not to bother.
> I think we have bigger fish to fry, and (to extend my nautical
> metaphor) trying to get this working everywhere might amount to trying
> to boil the ocean.
Well, I actually have a very, very preliminary patch using them in the
course of removing the spinlocks in PinBuffer() (via LockBufHdr()).
I think it's also going to be easier to add all required atomics at once
than having to go over several platforms in independent feature
patches adding atomics one by one.
> > I was thinking of something like:
> > include/storage/atomic.h
> > include/storage/atomic-gcc.h
> > include/storage/atomic-msvc.h
> > include/storage/atomic-acc-ia64.h
> > where atomic.h first has a list of #ifdefs including the specialized
> > files and then lots of #ifndef providing generic variants if not
> > already provided by the platorm specific file.
> Seems like we might want to put some of this in one of the various
> directories called "port", or maybe a new subdirectory of one of them.
Hm. I'd have to be src/include/port, right? Not sure if putting some
files there will be cleaner, but I don't mind it either.
> This basically sounds sane, but I'm unwilling to commit to dropping
> support for all obscure platforms we currently support unless there
> are about 500 people +1ing the idea, so I think we need to think about
> what happens when we don't have platform support for these primitives.
I think the introduction of the atomics really isn't much dependent on
the removal. The only thing I'd touch around platforms in that patch is
adding a generic fallback pg_atomic_test_and_set() to s_lock.h and
remove the special case usages of __sync_lock_test_and_set() (Arm64,
some 32 bit arms).
It's the patches that would like to rely on atomics that will have the
problem :(
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, tgl@sss.pgh.pa.us, pg@heroku.com, ants@cybertec.at
Subject: Re: better atomics
In-Reply-To: <20131016194541.GO5319@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