Re: better atomics - v0.5

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Ants Aasma <ants(at)cybertec(dot)at>
Subject: Re: better atomics - v0.5
Date: 2014-06-26 12:44:14
Message-ID: CAHyXU0zNuxzrdjOkDUmN5727WJHWpL0J6xxxVZZsY-vzH3bLhw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 26, 2014 at 5:20 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2014-06-25 20:16:08 -0400, Robert Haas wrote:
>> On Wed, Jun 25, 2014 at 4:36 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> > Since it better be legal to manipulate a atomic variable while holding a
>> > spinlock we cannot simply use an arbitrary spinlock as backing for
>> > atomics. That'd possibly cause us to wait on ourselves or cause
>> > deadlocks.
>>
>> 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 :).
>
> More seriously, I think we're not going to have much fun if we're making
> up the rule that you can't do an atomic add/sub while a spinlock is
> held. That just precludes to many use cases and will make the code much
> harder to understand. I don't think we're going to end up having many
> problems if we allow atomic read/add/sub/write in there.

That rule seems reasonable -- why would you ever want to do this?
While you couldn't properly deadlock it seems like it could lead to
unpredictable and hard to diagnose performance stalls.

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-06-26 12:49:42 Re: better atomics - v0.5
Previous Message Rushabh Lathia 2014-06-26 12:12:18 Re: "RETURNING PRIMARY KEY" syntax extension