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 <a...@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
