On 2014-09-26 08:39:38 -0400, Robert Haas wrote:
> On Fri, Sep 26, 2014 at 8:36 AM, Oskari Saarenmaa <os@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
storesto be reordered with other stores, but a load can be performed* before a subsequent store.** Technically, some
x86-ishchips 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
shouldbe 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