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 :/ > Right now, it's probably unsafe regardless. Yes, I have pretty little trust in the current state. Both from the infrastructure perspective (spinlocks, barriers) as from individual pieces of code. To a good part we're probably primarily protected by x86's black magic and the fact that everyone with sufficient concurrency to see problems uses x86. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
