Re: Spinlocks and compiler/memory barriers - Mailing list pgsql-hackers

On 2014-06-28 09:25:32 -0400, Robert Haas wrote:
> On Sat, Jun 28, 2014 at 4:31 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> >> > Do we want to introduce acquire/release barriers? Or do we want to
> >> > redefine the current barriers to be strong enough for that?
> >>
> >> Well, unless we're prepared to dump support for an awful lot of
> >> platfomrs, trying to support acquire and release barriers on every
> >> platform we support is a doomed effort.
> >
> > Hm? Just declare them to be as heavy as we need them? Already several
> > platforms fall back to more heavyweight operations than necessary?
> 
> Can't we keep this simple for starters?  Strength-reducing the
> existing operations is yet a third problem, on top of the
> already-existing problems of (1) making spinlock operations compiler
> barriers and (2) fixing any buggy implementations.  I'm explicitly
> trying to avoid defining this in a way that means we need a Gigantic
> Patch that Changes Everything.

I actually mean that we can just define release barriers to be full
memory barriers for platforms where we don't want to think about it. Not
that we should weaken barriers.

> No, I think it's going to be *much* simpler than that.  How about I
> take a crack at this next week and then either (a) I'll see why it's a
> bad idea and we can go from there or (b) you can review what I come up
> with and tell me why it sucks?

Ok. I think that's going in the wrong direction (duplication of
nontrivial knowledge), but maybe I'm taking a to 'purist' approach
here. Prove me wrong :)
You'll pick up the clobber changes from my patch?

> > How are you suggesting we deal with the generic S_UNLOCK
> > case without having a huge ifdef?
> > Why do we build an abstraction layer (barrier.h) and then not use it?
> 
> Because (1) the abstraction doesn't fit very well unless we do a lot
> of additional work to build acquire and release barriers for every
> platform we support and

Meh. Something like the (untested):
#if !defined(pg_release_barrier) && defined(pg_read_barrier) && defined(pg_write_barrier)
#define pg_release_barrier() do { pg_read_barrier(); pg_write_barrier();} while (0)
#elif !defined(pg_release_barrier)
#define pg_release_barrier() pg_memory_barrier()
#endif

before the fallback definition of pg_read/write_barrier should suffice?

> (2) I don't have much confidence that we can
> depend on the spinlock fallback for barriers without completely
> breaking obscure platforms, and I'd rather make a more minimal set of
> changes.

Well, it's the beginning of the cycle. And we're already depending on
barriers for correctness (and it's not getting less), so I don't really
see what avoiding barrier usage buys us except harder to find breakage?

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services