Re: Inefficient barriers on solaris with sun cc

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:

some stuff
CAS(&lock, 0, 1) // i am an acquire barrier
more stuff
lock = 0 // i am a release barrier
even more stuff

If the CAS() and lock = 0 instructions were FULL barriers, then we'd
be saying that the stuff that happens in the critical section needs to
be exactly "more stuff".  But if they are acquire and release
barriers, respectively, then the CPU is allowed to move "some stuff"
or "even more stuff" into the critical section; but what it can't do
is move "more stuff" out.

Now if you just have a naked acquire barrier that is not doing
anything itself, I don't really know what the semantics of that should
be.  Say I want to appear to only change things while flag is 1, so I
write this code:

flag = 1
acquire barrier
things++
release barrier
flag = 0

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!

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company