Re: better atomics - v0.5 - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: better atomics - v0.5
Date
Msg-id CAHyXU0zNuxzrdjOkDUmN5727WJHWpL0J6xxxVZZsY-vzH3bLhw@mail.gmail.com
Whole thread Raw
In response to Re: better atomics - v0.5  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: better atomics - v0.5  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Thu, Jun 26, 2014 at 5:20 AM, Andres Freund <andres@2ndquadrant.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@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Rushabh Lathia
Date:
Subject: Re: "RETURNING PRIMARY KEY" syntax extension
Next
From: Andres Freund
Date:
Subject: Re: better atomics - v0.5