Re: Inefficient barriers on solaris with sun cc

On Thu, Oct 2, 2014 at 11:18 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> So let's use those, then.
>
> Right, I've never contended that.

OK, cool.

>> A fully barrier on x86 should be an mfence, right?
>
> Right. I've not talked about changing full barrier semantics. What I was
> referring to is that until the atomics patch we always redefine
> read/write barriers to be full barriers when using gcc intrinsics.

OK, got it. If there's a cheaper way to tell gcc "loads before loads"
or "stores before stores", I'm fine with doing that for those cases.

>> > Which is why these acquire/release fences, in contrast to
>> > acquire/release operations, have more guarantees... You put your finger
>> > right onto the spot.
>>
>> But, uh, we still don't seem to know what those guarantees actually ARE.
>
> Paired together they form a synchronized-with relationship. Problem #1
> is that the standard's language isn't, to me at least, clear if there's
> not some case where that's not the case. Problem #2 is that our current
> README.barrier definition doesn't actually require barriers to be
> paired. Which imo is bad, but still a fact.

I don't know what a "synchronized-with relationship" means.

Also, I pretty much designed those definitions to match what Linux
does. And it doesn't require that either, though it says that in most
cases it will work out that way.

> The definition of ACQ_REL is pretty clearly sufficient imo: "Full
> barrier in both directions and synchronizes with acquire loads and
> release stores in another thread.".

I dunno. What's an acquire load? What's a release store? I know
what loads and stores are; I don't know what the adjectives mean.

>> The acquire
>> barrier guarantees that the load operations before the barrier will be
>> completed before the load and store operations after the barrier, but
>> the only operation before the barrier is a store, not a load, so it
>> guarantees nothing.
>
> Well, 'acquire' operations always have to related to a load.That's why
> standalone 'acquire fences' or 'acquire barriers' are more heavyweight
> than just a acquiring read.

Again, I can't judge any of this, because you haven't defined the
terms anywhere.

> And realistically, in the above example, you'd have to read flag to see
> that it's not already 1, right?

Not necessarily. You could be the only writer. Think about the way
the backend entries in the stats system work. The point of setting
the flag may be for other people to know whether the data is in the
middle of being modified.

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