[concurrency-interest] readValueUnderLock in ConcurrentHashMap

Pavitar Singh pavitar at pramati.com
Wed Apr 9 02:34:15 EDT 2008


"Because they are final. Final fields are guaranteed to be visible as
long as the object is not published before the constructor has
completed."

But object has been published even before constructor is completed. As
Threads can see it by going through table(tab)?

> Pavitar Singh wrote:
>> Hi All,
>>
>> I didnt understand why do we need readUnderLock during get in
>> ConcurrentHashMap.
>>
>> "This is possible only if a compiler happens to reorder a HashEntry
>> initialization with its table assignment, which is legal under memory
>> model          but is not known to ever occur."  from the javadoc.
>>
>> Does that mean :
>> in put method .
>>
>> tab[index] will have a HashEntry , but not yet initialized (constructor
>> invoked)
>
> It means that the HashEntry will not be completely initialized. So the
> volatile variable read might see the default initial value, which is null.
>
>> if this is the case then how HashEntry hash and key will be visible in:
>> get method.
>> if (e.hash == hash && key.equals(e.key))
>>
>
> Because they are final. Final fields are guaranteed to be visible as
> long as the object is not published before the constructor has
> completed. See 17.5 of the JLS:
> http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.5
>
> --
> Jason T. Greene
> JBoss, a division of Red Hat
>



More information about the Concurrency-interest mailing list