According to JCIP, a happens-before order also constitutes a safe
publication of the objects involved. Since there is a HB edge between the
put and the get, this leads to a safe publication of the object stored in
the map (safe publication is another JCIP term). JCIP also mentions CM
explicitly. So the original code works just fine.
It is not true that you need a synchronizes-with edge for safe publication.
In fact SW is insufficient for safe publication - see shipilevs "JMM
pragmatics". HB being sufficient for this is also the reason why you can't
see non-default field values in objects for example. There is a HB edge
from the default initialization to all other actions in the program.
HB order is pretty complicated so I prefer JCIPs "safe publication" model.
It makes the example very obviously correct, since mutable objects can be
shared as long as they're safely published, and a put on a concurrent map
constitutes safe publication. If you stick to JCIPs model, you will always
be on the safe side - you only need the full JMM if you really need to get
the last bit of performance :) (e.g. via piggy-backing)
- Jonas
Am Samstag, 17. November 2018 23:43:39 UTC+1 schrieb John Hening:
>
> 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.
>
> By the way, how to put an element safely (fully constructed) to
> ConcurrentHashMap if we need mutable object? I see only one solution (by
> adding a "mock" final field):
>
> class C {
> ..
> mutable fields
> ..
> final boolean publishSafely;
>
> }
>
>
>
> 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.
