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.viewcvs-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