[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.a++
storestore
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.
David
-----
More information about the core-libs-dev
mailing list