<p dir="ltr">As for Aleksey's point, I don't quite follow why initializing a final field off some racy field *requires* a LoadStore.  Eliminating StoreStore may happen, I guess, if something like escape analysis removes the allocation of an object with final field and scalar replaces it.  But again, unsure why another racy memory location requires LoadStore (unless this is talking about same thing as Hans in different terms).</p>
<p dir="ltr">Sent from my phone</p>
<div class="gmail_quote">On Sep 22, 2014 3:46 PM, "vikas" <<a href="mailto:vikas.vksingh@gmail.com">vikas.vksingh@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I was reading a article from Hans and he argues that LoadStore is also<br>
needed before lazySet or a final variable write (i assume then also before<br>
volatile write).<br>
<br>
He demonstrated a particular race condition which i couldn't understand<br>
(link below).<br>
<br>
<a href="http://www.hboehm.info/c++mm/no_write_fences.html" target="_blank">http://www.hboehm.info/c++mm/no_write_fences.html</a> see *Recipient writes to<br>
object*.<br>
<br>
Its very counter intuitive how  * store of x.a = 43* can be done past the<br>
StoreStore barrier in thread 1.<br>
*<br>
x.a = 0; x.a++;<br>
x_init.store_write_release(true);<br>
<br>
and the code that uses x in thread 2 updates it, with e.g.<br>
<br>
if (x_init.load_acquire())<br>
    x.a = 42;*<br>
<br>
<br>
Similar argument here <a href="http://shipilev.net/blog/2014/all-fields-are-final/" target="_blank">http://shipilev.net/blog/2014/all-fields-are-final/</a><br>
<br>
Copying Shiplev here :<br>
<br>
/JSR 133 Cookbook only requires StoreStore, but might also require LoadStore<br>
barriers. This covers for a corner case when the final field is getting<br>
initialized off some other field which experiences a racy update. *This<br>
corner case can be enabled by runtime optimization which figures out the<br>
final store is not needed, puts the value in the local variable, and hence<br>
breaks out of ordering guarantees of StoreStore alone*/<br>
<br>
How runtime can figure out that final Store is not needed, also if load is<br>
getting passed/reorder the StoreStore Barrier then Store to local Variable<br>
also is getting passed/reorder with the storeStore barrier, *This is the<br>
part i don't quite understand , why store to local variable can reorder with<br>
StoreStore Barrier. *<br>
<br>
It would be very help full if anybody can explain in more details what is<br>
the race condition they both are mentioning by some simple example.<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://jsr166-concurrency.10961.n7.nabble.com/LoadStore-and-StoreStore-are-both-are-required-before-lazySet-and-volatile-write-tp11291.html" target="_blank">http://jsr166-concurrency.10961.n7.nabble.com/LoadStore-and-StoreStore-are-both-are-required-before-lazySet-and-volatile-write-tp11291.html</a><br>
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.<br>
_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
</blockquote></div>