[concurrency-interest] Numa and ReentrantLock

Doug Lea dl at cs.oswego.edu
Sat Feb 26 11:16:26 EST 2011


On 02/26/11 10:39, Mohit Kumar wrote:
> Hi Doug,
>
> In the ConcurrentHashMap the get method does not require "readValueUnderLock"
> because a racing remove does not make the value null.
>
> Is my understanding correct.
>

Not quite. You are right that it should never be called.
However, the JLS/JMM can be read as not absolutely
forbidding it from being called because of weaknesses
in required ordering relationships among finals
vs volatiles set in constructors (key is final, value is
volatile), wrt the reads by threads using the
entry objects. (In JMM-ese, ordering constraints for
finals fall outside of the synchronizes-with relation.)
That's the issue the doc comment (pasted below) refers to.
No one has ever thought of any practical loophole that a
processor/compiler might find to produce a null value read,
and it may be provable that none exist (and perhaps someday
a JLS/JMM revision will fill in gaps to clarify this),
but Bill Pugh once suggested we put this in anyway just
for the sake of being conservatively pedantically correct.
In retrospect, I'm not so sure this was a good idea, since
it leads people to come up with exotic theories.

...

      * Because the value field is volatile, not final, it is legal wrt
      * the Java Memory Model for an unsynchronized reader to see null
      * instead of initial value when read via a data race.  Although a
      * reordering leading to this is not likely to ever actually
      * occur, the Segment.readValueUnderLock method is used as a
      * backup in case a null (pre-initialized) value is ever seen in
      * an unsynchronized access method.
      */
     static final class HashEntry<K,V> {
         final K key;
         final int hash;
         volatile V value;
         final HashEntry<K,V> next;


More information about the Concurrency-interest mailing list