Gil, thank you.
In the docs it is written Retrievals reflect the results of the most recently *completed* update > operations holding upon their onset. (More formally, an update operation > for a given key bears a *happens-before* relation with any (non-null) > retrieval for that key reporting the updated value.) > > and, ineed, you right. It is too generally written. Actually it points a HB relation between updating and getting value but we cannot conclude that there is a HB between initialization of element and getting it (nonnull). So, for users of ConcurrentHashMap it means completely nothing because we don't need to take care of implementation details. W dniu sobota, 17 listopada 2018 22:46:51 UTC+1 użytkownik Gil Tene napisał: > > 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 CHM. 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
