On 2014-09-26 08:39:38 -0400, Robert Haas wrote: > On Fri, Sep 26, 2014 at 8:36 AM, Oskari Saarenmaa <o...@ohmu.fi> wrote: > > 25.09.2014, 16:34, Andres Freund kirjoitti: > >> Binaries compiled on solaris using sun studio cc currently don't have > >> compiler and memory barriers implemented. That means we fall back to > >> relatively slow generic implementations for those. Especially compiler, > >> read, write barriers will be much slower than necessary (since they all > >> just need to prevent compiler reordering as both sparc and x86 are run > >> in TSO mode under solaris). > > > > Attached patch implements compiler and memory barriers for Solaris Studio > > based on documentation at > > http://docs.oracle.com/cd/E18659_01/html/821-1383/gjzmf.html > > > > I defined read and write barriers as acquire and release barriers instead of > > pure read and write ones as that's what other platforms appear to do. > > So you think a read barrier is the same thing as an acquire barrier > and a write barrier is the same as a release barrier? That would be > surprising. It's certainly not true in general.
It's generally true that a read barrier is implied by an acquire barrier, no? Same for write barriers being implied by read barriers. Neither is true the other way round, but that's fine. Given how postgres uses memory barriers we actually could declare read/write barriers to be compiler barriers when on solaris. Both supported architectures (x86, sparc) are run in TSO mode. As the existing barrier code for x86 says: * Both 32 and 64 bit x86 do not allow loads to be reordered with other loads, * or stores to be reordered with other stores, but a load can be performed * before a subsequent store. * * Technically, some x86-ish chips support uncached memory access and/or * special instructions that are weakly ordered. In those cases we'd need * the read and write barriers to be lfence and sfence. But since we don't * do those things, a compiler barrier should be enough. * * "lock; addl" has worked for longer than "mfence". It's also rumored to be * faster in many scenarios Unless I miss something the same is true for sparc *in solaris userland*. But I'd be perfectly happy to go with something like Oksari's version because it's still much better than the current code. 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
