Re: Spinlocks and compiler/memory barriers

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Spinlocks and compiler/memory barriers
Date: 2014-06-28 13:25:32
Message-ID: CA+TgmoZuTiQsXNfEhS7CuSDXrVGkzWpJe5kOfNLfGObKd=GcYQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-06-28 13:41:46 Re: Spinlocks and compiler/memory barriers
Previous Message Andres Freund 2014-06-28 13:08:45 Re: Cluster name in ps output