Bill,
You wrote:
"In general, a JVM is not allowed to reorder a volatile write with any
preceding accesses to shared memory."
I couldn't find this constraint in the JMM document. Should I be looking
elsewhere for the definition of this constraint?
_____________________________________________________
Evan Ireland eireland@sybase.com +64 4 934-5856
Sybase EAServer Engineering, Wellington, New Zealand.
_____________________________________________________
> -----Original Message-----
> From: owner-javamemorymodel@cs.umd.edu
> [mailto:owner-javamemorymodel@cs.umd.edu]On Behalf Of Bill Pugh
> 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
-------------------------------
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