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. > 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? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
