[jmm-dev] Will the real memory read barrier please stand up?

[Hans Boehm]

I agree that the third definition is nonsensical unless a LoadFenceNode is
attached to a specific load.  That seems implausible given the rest of your
description.

There doesn't seem to be any consistency about the use of definition 1 or
2.  I think a definition 1 "read barrier" has very limited utility, but
some architectures provide it.  ARMv8's load barrier is type 2, but ARM's
store barrier is the analog of type 1, i.e. it orders only stores.

Hans

On Wed, Nov 19, 2014 at 11:12 AM, Martin Buchholz <martinrb at google.com>
wrote:

> I'm struggling to educate myself about memory barriers, and I
> discovered both Paul McKenney's awesome book and those newfangled
> Unsafe fences in OpenJDK.  Paul's book says
>
> """A read barrier is a partial ordering on loads only; it is not
> required to have any effect on stores."""
>
> Meanwhile,  Unsafe.loadFence doc says,
>
> """Ensures lack of reordering of loads before the fence with loads or
> stores after the fence."""
>
> Spelunking in the hotspot sources, Unsafe.loadFence is implemented via
> LoadFenceNode, which says:
>
> """"Acquire" - no following ref can move before (but earlier refs can
> follow, like an early Load stalled in cache)"""
>
> So ... that's 3 different definitions?!  Further, the doc for
> LoadFenceNode seems non-sensical to me - if following refs (load or
> store) can cross the barrier backwards, how is that different in
> effect from allowing preceding refs to cross the barrier forwards?
> Both seem to allow any reordering at all?!  Should that have read
> """but earlier Stores (perhaps stalled in cache) can follow""" ?
>