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

Martin Buchholz martinrb at google.com
Thu Nov 20 03:27:43 UTC 2014


Maybe enlightenment can be found at preshing.com
http://preshing.com/20130922/acquire-and-release-fences/

Is Unsafe.loadFence precisely C11 atomic_thread_fence(memory_order_acquire);
Is Unsafe.storeFence precisely C11 atomic_thread_fence(memory_order_release);

If so, it would be nice if it said so!

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""" ?


More information about the jmm-dev mailing list