[concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics
peter.levart at gmail.com
Wed Dec 17 09:28:30 UTC 2014
On 12/17/2014 03:28 AM, David Holmes wrote:
> 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:
>> 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.
Perhaps, he is speaking about why it is dangerous to replace BOTH
release with just store-store AND acquire with just load-load?
The example would then become:
store x.a <- 0
load r <- x.a
store x.a <- r+1
store x_init <- true
load r <- x.a
store x.a <- 42
Suppose a "store" on some hypothetical architecture is actually a
two-phase execution: prepare-store, commit-store
With prepare-store imagined as speculative posting of store to the write
buffer and commit-store just marking it in the write buffer as commited,
so that is is written to main memory on write buffer flush. Non commited
stores are not written to main memory, but are allowed to be visible to
loads in some threads (executing on same core?) which are not ordered by
load-store before the speculative prepare-store. A load-load does not
prevent the T2 to be executed as following:
prepare-store x.a <- 42
load r <- x.a
commit-store x.a <- 42
Now this speculative prepare-store can (in real time) happen long before
T1 instructions are executed. The loads in T1 are then allowed to "see"
this speculative prepare-store from T2, because just store-store does
not logically order them in any way - only load-store would.
Does this make sense?
More information about the core-libs-dev