On Tue, Nov 19, 2013 at 10:31 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
