ConcurrentHashMap reorder instruction?

Question

I\'m looking into ConcurrentHashMap implementation and have a thing make me confused.

/* Specialized implementations of map methods */

        V get(Object          


        

Answer 1

As far as I understand Memory Model, write to volatile variable is guaranteed to be visible by all subsequent (as defined by synchronization order) reads of that variable.

However, nothing guarantees that read of e.value in get() is subsequent to write of value in the constructor (since there are no synchronized-with relations between these actions), so that Memory Model allows this kind of reorder, and explicit synchronization in the case of null value is necessary to ensure that we read the correct value.

UPDATE: The new memory model guarantees that any write to non-volatile variable prior to write to the volatile variable can be seen by other threads after the subsequent read of that volatile variable, but not vice versa.

Here is the related excerpt from The Java Memory Model by Jeremy Manson, William Pugh and Sarita Adve:

5.1.1 Lock Coarsening.
...
All of this is simply a roundabout way of saying that accesses to normal variables can be reordered with a following volatile read or lock acquisition, or a preceding volatile write or lock release. This implies that normal accesses can be moved inside locking regions, but (for the most part) not out of them;

Therefore assignment of the constructed object can be reordered with the write to volatile variable inside a constructor, so that the check in question is required.