26.09.2014, 15:39, Robert Haas kirjoitti:
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.
The above doc describes the difference: read barrier requires loads
before the barrier to be completed before loads after the barrier - an
acquire barrier is the same, but it also requires loads to be complete
before stores after the barrier.
Similarly write barrier requires stores before the barrier to be
completed before stores after the barrier - a release barrier is the
same, but it also requires loads before the barrier to be completed
before stores after the barrier.
So acquire is read + loads-before-stores and release is write +
loads-before-stores.
The generic gcc atomics also define read barrier to __ATOMIC_ACQUIRE and
write barrier to __ATOMIC_RELEASE.
/ Oskari
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
