Do LoadStore and StoreStore are both needed for a final variable and lazySet implementation?

Question

I was reading a article from Hans and he argues that LoadStore is also needed before lazySet or a final variable write .

He demonstrate a particular race condition which i couldn't understand .

http://www.hboehm.info/c++mm/no_write_fences.html see Recipient writes to object.

Its very counterintuitive how thread 1 store of x.a = 43 can be done past the StoreStore barrier because then it totally defeats the purpose of StoreStore Barrier.

Similar argument here http://shipilev.net/blog/2014/all-fields-are-final/

Copying Shiplev here :

"JSR 133 Cookbook only requires StoreStore, but might also require LoadStore barriers. This covers for a corner case when the final field is getting initialized off some other field which experiences a racy update. This corner case can be enabled by runtime optimization which figures out the final store is not needed, puts the value in the local variable, and hence breaks out of ordering guarantees of StoreStore alone"

*How runtime can figure out final Store is not needed, also if load is getting passed/reorder the StoreStore Barrier then Store to local Variable also is getting passed/reorder with the storeStore barrier, this is the part i don't quite understand , why store to local variable can reorder with StoreStore Barrier. How/When the runtime can figure out that store to local variable will suffice *

It would be very help full if anybody can explain in more details what is the race condition they both are mentioning by some simple example.

Answer 1

The quote from my post is confusing and obsolete, I fixed it long ago; sorry for the confusion. You are welcome to drop me a mail next time it happens. Really, it follows Hans Boehm's example, that is fairly simple:

x.a = 0; x.a++;
x_init.store_write_release(true);

and the code that uses x in thread 2 updates it, with e.g.

if (x_init.load_acquire())
    x.a = 42;

If the release store in thread 1 were restricted to only ensure completion of prior stores (writes), the load of x.a in thread 1 (part of x.a++) could effectively be reordered with the assignment x_init, and could hence see a value of 42, causing x.a to be initialized to 43.