I'd be happy to be wrong here, but...

This statement in the CHM contract (JavaDoc quoted below) establishes a 
happens-before relationship between the put into the CHM and any (non-null) 
retrieval form the CGHM. It amounts to a safe publication within the CHM 
itself, but does not read on the constructor of the value being put() into 
the CHM. There is no contract I've found that establishes a 
happens-before relationship between the initialization of non-final fields 
in some object construction and the put of that object (or of some object 
that refers to it) as a value into the CHM.

It is true that* in current implementation* a put() involves a volatile 
store of the value into a Node<K,V>.val field 
<https://github.com/bpupadhyaya/openjdk-8/blob/master/jdk/src/share/classes/java/util/concurrent/ConcurrentHashMap.java#L622>,
 
and that this volatile store does establish the needed happens-before 
relationship between constructor initialization of non-final fields in the 
value object and subsequent reads from the val field (including subsequent 
get() operations that return that value object). But (AFAICT) that quality 
can only be deduced by reading the source code of a current implementation.

It is also true that future implementations of CHM will *likely* maintain 
similar qualities since they seem to be desirable and de-facto provided 
currently, so it may be surprising for them to disappear in some future CHM 
implementation.

But AFAICT, nowhere in the CHM contract, or in the spec, does it actually 
say that this relationship (a happens-before between non-final field 
initialization in a constructor and an eventual get() of the constructed 
object from a CHM) can be counted on.

If someone finds that missing statement (in the documentation, not the 
implementation source statements) that would provide the full 
happens-before links to non-final-field initialization, please point it out.

On Saturday, November 17, 2018 at 2:04:32 AM UTC-8, Vladimir Sitnikov wrote:
>
> > storing into a CHM is a safe publication
>
> +1
>
> That's declared in CHM JavaDoc: 
>
> More formally, an update operation for a given key bears a
> * <em>happens-before</em> relation with any (non-null) retrieval for
> * that key reporting the updated value.
>
> Vladimir
>

-- 
You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mechanical-sympathy+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to