On Tue, Nov 19, 2013 at 10:31 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-11-19 10:23:57 -0500, Robert Haas wrote:
>> > The only fundamental thing that I don't immediately see how we can
>> > support is the spinlock based memory barrier since that introduces a
>> > circularity (atomics need barrier, barrier needs spinlocks, spinlock
>> > needs atomics).
>>
>> We've been pretty much assuming for a long time that calling a
>> function in another translation unit acts as a compiler barrier.
>> There's a lot of code that isn't actually safe against global
>> optimization; we assume, for example, that memory accesses can't move
>> over an LWLockAcquire(), but that's just using spinlocks internally,
>> and those aren't guaranteed to be compiler barriers, per previous
>> discussion. So one idea for a compiler barrier is just to define a
>> function call pg_compiler_barrier() in a file by itself, and make that
>> the fallback implementation. That will of course fail if someone uses
>> a globally optimizing compiler, but I think it'd be OK to say that if
>> you want to do that, you'd better have a real barrier implementation.
>
> That works for compiler, but not for memory barriers :/
True, but we already assume that a spinlock is a memory barrier minus
a compiler barrier. So if you have a working compiler barrier, you
ought to be able to fix spinlocks to be memory barriers. And then, if
you need a memory barrier for some other purpose, you can always fall
back to acquiring and releasing a spinlock.
Maybe that's too contorted.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
