On Thu, Jun 26, 2014 at 12:20:06PM +0200, Andres Freund 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.
I agree it's valuable to have a design that permits invoking an atomic
operation while holding a spinlock.
> > > I added the x86 inline assembler because a fair number of buildfarm
> > > animals use ancient gcc's and because I could easily test it. It's also
> > > more efficient for gcc < 4.6. I'm not wedded to keeping it.
> >
> > Hmm. gcc 4.6 is only just over a year old, so if pre-4.6
> > implementations aren't that good, that's a pretty good argument for
> > keeping our own implementations around. :-(
GCC 4.6 was released 2011-03-25, though that doesn't change the bottom line.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com
