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

[Peter Levart]

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:
>> 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
> -----
>

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:

T1:

store x.a <- 0
load r <- x.a
store x.a <- r+1
; store-store
store x_init <- true

T2:

load r <- x.a
; load-load
if (r)
     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:

T2:

prepare-store x.a <- 42
load r <- x.a
; load-load
if (r)
     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?

Regards, Peter