On Thu, Oct 2, 2014 at 2:06 PM, Andres Freund <andres@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
