On 2014-10-06 11:38:47 -0400, Robert Haas wrote: > On Thu, Oct 2, 2014 at 2:06 PM, Andres Freund <and...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
