Re: Spinlocks and compiler/memory barriers

On Sat, Jun 28, 2014 at 4:31 AM, Andres Freund <andres(at)2ndquadrant(dot)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.

>> The definitions of the
>> barriers implemented by barrier.h are the same as the ones that Linux
>> has (minus read-barrier-depends)
>
> Linux has smb_load_acquire()/smp_store_release() for locks on all
> platforms.

You mean "smp".

>> If we were going
>> to use any of those in s_lock.h, it'd have to be pg_memory_barrier(),
>> but I don't think making s_lock.h dependent on barrier.h is the way to
>> go. I think we should just adjust s_lock.h in a minimal way, using
>> inline assembler or tweaking the existing assembler or whatever.
>
> Isn't that just going to be repeating the contents of barrier.h pretty
> much again?

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?

> 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 (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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company