26.09.2014, 17:28, Robert Haas kirjoitti:
> On Fri, Sep 26, 2014 at 8:55 AM, Oskari Saarenmaa <os@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
