[concurrency-interest] 8145539: (coll) AbstractMap.keySet and .values should not be volatile

thurstonn thurston at nomagicsoftware.com
Tue Apr 26 11:00:59 EDT 2016


Yes, I understand the compiler transformation that could cause the problem,
and that it's allowed by the JMM, but I find it hard to believe that there's
an actual JIT out there in the wild that would actually do so.
The "normal", logical optimization would be to eliminate the redundant read,
which actually "solves" the data race.

It's one thing for the compiler (or more likely the CPU) to reorder reads of
*different memory locations*, but to reorder reads of *the same memory
location*?  That seems far-fetched.

Anyway, I'll take a look at the link.


*I should note that the problem wouldn't have manifested itself in
AbstractMap since #keyset and #values were originally declared volatile; I
was asking about the general idiom 


Vitaly Davidovich wrote
> The problem is compilers can do weird things on the assumption of data
> race
> free code.  If you haven't seen
> https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong,
> I recommend reading it.  It's in the context of C/C++/Go but the general
> point stands.
> 
> In this case, compiler can arrange a read of the field into a
> register/stack slot - assume it reads null.  Later it re-tests the field
> (memory), sees non null, but returns the register/stack slot value.  It's
> weird, but legal.  Whether it happens I don't know, but you likely don't
> want to find out :).
> 
> On Monday, April 25, 2016, thurstonn <

> thurston@

> > wrote:
> 
>> Just curious,
>>
>> has anyone actually observed a real JVM returning null in the original,
>> racy
>> code?
>> I realize the JMM allows it, but I'd be surprised that a JVM would
>> reorder
>> reads of the *same* memory location
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://jsr166-concurrency.10961.n7.nabble.com/8145539-coll-AbstractMap-keySet-and-values-should-not-be-volatile-tp13382p13403.html
>> Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
>> _______________________________________________
>> Concurrency-interest mailing list
>> 

> Concurrency-interest at .oswego

>  <javascript:;>
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
> 
> 
> -- 
> Sent from my phone
> 
> _______________________________________________
> Concurrency-interest mailing list

> Concurrency-interest at .oswego

> http://cs.oswego.edu/mailman/listinfo/concurrency-interest





--
View this message in context: http://jsr166-concurrency.10961.n7.nabble.com/8145539-coll-AbstractMap-keySet-and-values-should-not-be-volatile-tp13382p13408.html
Sent from the JSR166 Concurrency mailing list archive at Nabble.com.


More information about the Concurrency-interest mailing list