From: Andres Freund <andres@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter_e@gmx.net>
Cc: Peter Geoghegan <pg@heroku.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Cc: Ants Aasma <ants@cybertec.at>
Subject: Re: better atomics - v0.2
Date: Tue, 19 Nov 2013 16:31:06 +0100
Message-ID: <20131119153106.GA19293@alap2.anarazel.de> (raw)
In-Reply-To: <CA+TgmoaO-2GxU-2GCRXfytY5gHk-NeEVrMfKUbYQLzyCZv-E3A@mail.gmail.com>
References: <CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com>
<20131115200416.GH5489@awork2.anarazel.de>
<CA+Tgmobhd5hwC+NzCfn2p1MO8EHZjhNgFQyLcA-cjRtSJzZJ6Q@mail.gmail.com>
<8392.1384873040@sss.pgh.pa.us>
<20131119151646.GD10498@alap2.anarazel.de>
<CA+TgmoaO-2GxU-2GCRXfytY5gHk-NeEVrMfKUbYQLzyCZv-E3A@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 2013-11-19 10:23:57 -0500, Robert Haas wrote:
> > The only fundamental thing that I don't immediately see how we can
> > support is the spinlock based memory barrier since that introduces a
> > circularity (atomics need barrier, barrier needs spinlocks, spinlock
> > needs atomics).
>
> We've been pretty much assuming for a long time that calling a
> function in another translation unit acts as a compiler barrier.
> There's a lot of code that isn't actually safe against global
> optimization; we assume, for example, that memory accesses can't move
> over an LWLockAcquire(), but that's just using spinlocks internally,
> and those aren't guaranteed to be compiler barriers, per previous
> discussion. So one idea for a compiler barrier is just to define a
> function call pg_compiler_barrier() in a file by itself, and make that
> the fallback implementation. That will of course fail if someone uses
> a globally optimizing compiler, but I think it'd be OK to say that if
> you want to do that, you'd better have a real barrier implementation.
That works for compiler, but not for memory barriers :/
> Right now, it's probably unsafe regardless.
Yes, I have pretty little trust in the current state. Both from the
infrastructure perspective (spinlocks, barriers) as from individual
pieces of code. To a good part we're probably primarily protected by
x86's black magic and the fact that everyone with sufficient concurrency
to see problems uses x86.
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, peter_e@gmx.net, pg@heroku.com, ants@cybertec.at
Subject: Re: better atomics - v0.2
In-Reply-To: <20131119153106.GA19293@alap2.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