26.09.2014, 15:39, Robert Haas kirjoitti:
> 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.
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