[concurrency-interest] ConcurrentHashMap: HashEntry.value potentially null to readers comment

Dawid Weiss dawid.weiss at gmail.com
Tue Jun 21 03:56:02 EDT 2011


Thanks Doug, I appreciate your time. This quote is exactly what we were doing:

> In retrospect, I'm not so sure this was a good idea, since
> it leads people to come up with exotic theories.

Dawid

On Tue, Jun 21, 2011 at 9:48 AM, Doug Lea <dl at cs.oswego.edu> wrote:
>> Hello everyone,
>>
>> The questions concerning safe publication, final fields and visibility
>> pop up from time to time and I have tracked the list's archives, but
>> couldn't find an appropriate answer.
>
> The last version of this discussion is hiding under an uninformative
> subject line in the March 2011 archives, esp message 007799
> http://cs.oswego.edu/pipermail/concurrency-interest/2011-March/007799.html
>
> Btw, the jdk7 version of this class doesn't use this recheck, because we
> now use a volatile read to allow for lazier initialization, which reduces
> footptint.
>
> -Doug
>
>>
>> ConcurrentHashMap.HashEntry has the following fields:
>>
>>         final K key;
>>         final int hash;
>>         volatile V value;
>>         final HashEntry<K,V> next;
>>
>> the only constructor assigns them in this order:
>>
>>             this.key = key;
>>             this.hash = hash;
>>             this.next = next;
>>             this.value = value;
>>
>> it is clear to us that all final fields will be published safely; the
>> comment in that class states that:
>>
>>      * Because the value field is volatile, not final, it is legal wrt
>>      * the Java Memory Model for an unsynchronized reader to see null
>>
>> QUESTION 1. The first question is for the possible rationale of
>> publishing a reference to a partially constructed object to memory. As
>> compiler writers does anybody know when would such an optimization be
>> speeding up things or be at all advisable? Or is it just protecting
>> oneself against JMM memory model scenario that hardly ever takes place
>> in the real generated code (as actually stated in the comment to
>> readValueUnderLock)?
>>
>> QUESTION 2. Would the above scenario change if we reordered
>> assignments so that volatile variable is assigned first (before final
>> fields)? As in here:
>>
>>             this.value = value;
>>             this.key = key;
>>             this.hash = hash;
>>             this.next = next;
>>
>> It is my understanding that final field assignments must precede the
>> publication of the object's reference; is this freely reorderable with
>> respect to volatile writes?
>>
>> QUESTION 3. This one is about assignment piggybacking using volatiles.
>> If we had a hardware architecture that would allow selective cache
>> flushes (to single-cell memory addresses, for example), must writing
>> to a volatile enforce a flush of all of the thread's caches? Really?
>> If so the only "gain" over full monitors is no need for thread locking
>> (only a cache flush), right? I don't see the JLS stating such a thing,
>> but I admit the section about happens-before algebra is pretty dense
>> to me.
>>
>> Thanks in advance for all the help or pointers to relevant discussion
>> elsewhere.
>> Dawid
>>
>>
>> Dawid
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>
>
>



More information about the Concurrency-interest mailing list