RE: JavaMemoryModel: Question about implementation of java.util.concurrent.ConcurrentHashMap

From: Evan Ireland (eireland@sybase.com)
Date: Thu Nov 13 2003 - 14:37:23 EST


Bill (and others),

You wrote:

    "In general, a JVM is not allowed to reorder a volatile write with any
> preceding accesses to shared memory."

Although I found reference to this in the JMM archives, I could not
find this statement in the community review 2 JMM document.

Is it unintentionally missing from the document?

(Please excuse if this is a repeat. I thought I already sent a similar
message but couldn't find it in my "Sent Items" folder.)

> -----Original Message-----
> From: Bill Pugh [mailto:pugh@cs.umd.edu]
> Sent: Wednesday, 12 November 2003 5:47 a.m.
> To: eireland@sybase.com; Java Memory Model
> Subject: Re: JavaMemoryModel: Question about implementation of
> java.util.concurrent.ConcurrentHashMap
>
>
> At 4:59 PM +1300 11/11/03, Evan Ireland wrote:
> >Folks,
> >
> >I was just reviewing an implementation of
> >java.util.concurrent.ConcurrentHashMap
> >
> >
> >http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java
> /util/concu
> >rrent/ConcurrentHashMap.java?rev=1.28&content-type=text/vnd.viewc
> vs-markup
> >
> >and with respect to the latest memory model document I was
> unable to see how
> >or why the implementation of method 'put' in inner class Segment ensures
> >proper visibility of writes. Specifically, if an entry is
> updated in place
> >we will execute:
> >
> >for (HashEntry<K,V> e = first; e != null; e = (HashEntry<K,V>) e.next)
> >{
> > if (e.hash == hash && key.equals(e.key))
> > {
> > V oldValue = e.value;
> > if (!onlyIfAbsent)
> > e.value = value;
> > ++modCount;
> > count = c; // write-volatile
> > return oldValue;
> > }
> >}
> >
> >I cannot determine why the assignment to volatile 'count' will ensure
> >visibility (to reader threads which do not acquire a lock) of the
> >preceeding change to e.value (the 'value' field is non-volatile).
> >Although "e.value = value" happens before "count = c" in the code, the
> >compiler could presumably reorder the assignment "e.value = value"
> >after "count = c", since it is clear that 'e' cannot be null.
>
> In general, a JVM is not allowed to reorder a volatile write with any
> preceding accesses to shared memory.
>
> There are, of course, plenty of exceptions (e.g., if the volatile is
> thread local, then the reordering is allowed). But it provides the
> guarantees needed to make this code work.
>
> Bill
>
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:53 EDT