[concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

David Holmes david.holmes at oracle.com
Wed Dec 17 02:28:25 UTC 2014

On 17/12/2014 10:06 AM, Martin Buchholz wrote:
> On Thu, Dec 11, 2014 at 1:08 AM, Andrew Haley <aph at redhat.com> wrote:
>> On 11/12/14 00:53, David Holmes wrote:
>>> There are many good uses of storestore in the various lock-free
>>> algorithms inside hotspot.
>> There may be many uses, but I am extremely suspicious of how good
>> they are.  I wonder if we went through all the uses of storestore in
>> hotspot how many bugs we'd find.  As far as I can see (in the absence
>> of other barriers) the only things you can write before a storestore
>> are constants.
> Hans has provided us with the canonical writeup opposing store-store
> and load-load barriers, here:
> http://www.hboehm.info/c++mm/no_write_fences.html
> Few programmers will be able to deal confidently with causality
> defying time paradoxes, especially loads from "the future".

Well I take that with a grain of salt - Hans dismisses ordering based on 
dependencies which puts us into the realm of those "causality defying 
time paradoxes" in my opinion. Given:

x.a = 0;
x_init = true

Hans allows for the nonsensical, in my view, possibility that the load 
of x.a can happen after the x_init=true store and yet somehow be subject 
to the ++ and the ensuing store that has to come before the x_init = true.


More information about the core-libs-dev mailing list