From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Oskari Saarenmaa <os(at)ohmu(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Inefficient barriers on solaris with sun cc |
Date: | 2014-10-06 15:42:08 |
Message-ID: | 20141006154208.GA3007@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2014-10-06 11:38:47 -0400, Robert Haas wrote:
> On Thu, Oct 2, 2014 at 2:06 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> >> 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.
> >
> > My point is that that read barriers aren't particularly meaningful
> > without a defined store order from another thread/process. Without any
> > form of pairing you don't have that. The writing side could just have
> > reordered the writes in a way you didn't want them. And the kernel docs
> > do say "A lack of appropriate pairing is almost certainly an error". But
> > since read barriers also pair with lock releases operations, that's
> > normally not a big problem.
>
> Agreed, but it's possible to have a read-fence where an atomic
> operation provides the ordering on the other side, or something like
> that.
Sure, that's one of the possible pairings. Most atomics have barrier
semantics...
> > I'm still unsure what you want to show with that example?
>
> Me, too. I think we've drifted off in the weeds. Do we know what we
> need to know to fix $SUBJECT?
I think we can pretty much apply Oskari's patch after replacing
acquire/release with read/write intrinsics.
I'm opening a bug with the gcc folks about clarifying the docs on their
intrinsics.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-10-06 15:50:07 | Re: [RFC] Incremental backup v2: add backup profile to base backup |
Previous Message | Robert Haas | 2014-10-06 15:38:47 | Re: Inefficient barriers on solaris with sun cc |