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.
I thought I understood that the happens-before relationship was the only
thing guaranteeing visibility. Either:
(1) I didn't understand it.
(2) The code is broken.
Can someone please enlighten me.
Thanks.
_____________________________________________________
Evan Ireland eireland@sybase.com +64 4 934-5856
Sybase EAServer Engineering, Wellington, New Zealand.
_____________________________________________________
-------------------------------
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