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

Vitaly Davidovich vitalyd at gmail.com
Tue Apr 26 08:27:12 EDT 2016


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 at nomagicsoftware.com> 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 cs.oswego.edu <javascript:;>
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>


-- 
Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160426/703c74f7/attachment.html>


More information about the Concurrency-interest mailing list