26.09.2014, 17:28, Robert Haas kirjoitti:
On Fri, Sep 26, 2014 at 8:55 AM, Oskari Saarenmaa <o...@ohmu.fi> wrote:
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.
Hmm. My impression was that an acquire barrier means that loads and
stores can migrate forward across the barrier but not backward; and
that a release barrier means that loads and stores can migrate
backward across the barrier but not forward. I'm actually not really
sure what this means unless the barrier also does something in and of
itself. For example, consider this:
[...]
With the definition you (and Oracle) propose, this won't work, because
there's nothing to keep the modification of things from being
reordered before flag = 1. What good is that? Apparently, I don't
have any idea!
I'm not proposing any definition for acquire or release barriers, I was
just proposing to use the things Solaris Studio defines as acquire and
release barriers to implement read and write barriers in PostgreSQL
because similar barrier names are used with gcc and on Solaris Studio
acquire is a stronger read barrier and release is a stronger write
barrier. atomics.h's definition of pg_(read|write)_barrier doesn't have
any requirements for loads before stores, though, so we could use
__machine_r_barrier and __machine_w_barrier instead.
But as Andres pointed out all this is probably unnecessary and we could
define read and write barrier as __compiler_barrier with Solaris Studio
cc. It's only available for Solaris (x86 and Sparc) and Linux (x86).
/ Oskari
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
