From: Andres Freund <andres@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>
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 21:04:05 +0200
Message-ID: <20140626190405.GA21422@awork2.anarazel.de> (raw)
In-Reply-To: <54412.1403808435@sss.pgh.pa.us>
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>
<CA+TgmoY4OqKa9=G+5F0s0gPTpOB4cz=Mts34jrdf8399MWGcqw@mail.gmail.com>
<20140626102006.GB1926@awork2.anarazel.de>
<CA+TgmoYUQ17UFfG3S-zctOdT9ba3cuW-J7TmfzKPF_N=nkqCEw@mail.gmail.com>
<54412.1403808435@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
On 2014-06-26 11:47:15 -0700, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Thu, Jun 26, 2014 at 6:20 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> >> On 2014-06-25 20:16:08 -0400, Robert Haas wrote:
> >>> I think that's going to fall afoul of Tom's previously-articulated "no
> >>> loops inside spinlocks" rule. Most atomics, by nature, are
> >>> loop-until-it-works.
>
> >> Well, so is TAS itself :).
>
> > Yeah, which is why we have a rule that you're not suppose to acquire
> > another spinlock while already holding one. You're trying to make the
> > spinlocks used to simulate atomic ops an exception to that rule, but
> > I'm not sure that's OK. An atomic op is a lot more expensive than a
> > regular unlocked load or store even if it doesn't loop, and if it does
> > loop, it's worse, potentially by a large multiple.
>
> Well, the point here is to be sure that there's a reasonably small bound
> on how long we hold the spinlock. It doesn't have to be zero, just small.
>
> Would it be practical to say that the coding rule is that you can only
> use atomic ops on fields that are protected by the spinlock, ie, nobody
> else is supposed to be touching those fields while you have the spinlock?
> If that's the case, then the atomic op should see no contention and thus
> not take very long.
I don't really see usecases where it's not related data that's being
touched, but: The point is that the fastpath (not using a spinlock) might
touch the atomic variable, even while the slowpath has acquired the
spinlock. So the slowpath can't just use non-atomic operations on the
atomic variable.
Imagine something like releasing a buffer pin while somebody else is
doing something that requires holding the buffer header spinlock.
> On the other hand, if the atomic op is touching something not protected
> by the spinlock, that seems to me to be morally equivalent to taking a
> spinlock while holding another one, which as Robert says is forbidden
> by our current coding rules, and for very good reasons IMO.
>
> However, that may be safe only as long as we have real atomic ops.
> If we're simulating those using spinlocks then you have to ask questions
> about how many underlying spinlocks there are and whether artificial
> contention might ensue (due to the same spinlock being used for multiple
> things).
With the code as submitted it's one spinlock per atomic variable. Which
is fine until spinlocks are emulated using semaphores - in that case a
separate array of semaphores (quite small in the patch as submitted) is
used so there's no chance of deadlocks against a 'real' spinlock or
anything like that.
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, tgl@sss.pgh.pa.us, robertmhaas@gmail.com, pg@heroku.com, ants@cybertec.at
Subject: Re: better atomics - v0.5
In-Reply-To: <20140626190405.GA21422@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