[concurrency-interest] LoadStore and StoreStore , are both are required before lazySet and volatile write

vikas vikas.vksingh at gmail.com
Mon Sep 22 15:14:45 EDT 2014

I was reading a article from Hans and he argues that LoadStore is also
needed before lazySet or a final variable write (i assume then also before
volatile write).

He demonstrated a particular race condition which i couldn't understand 
(link below).

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

Its very counter intuitive how  * store of x.a = 43* can be done past the
StoreStore barrier in thread 1.
x.a = 0; x.a++;

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

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

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 that 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. *

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.

View this message in context: http://jsr166-concurrency.10961.n7.nabble.com/LoadStore-and-StoreStore-are-both-are-required-before-lazySet-and-volatile-write-tp11291.html
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.

More information about the Concurrency-interest mailing list