> 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.
>
According to the latest JMM proposal, JMM has two requirements:
happens-before consistency and causality. HB consistency states that a read
r is allowed to observe a write w if r does not happen before (HB) w and
there is no intervening write w1 such that w HB w1 HB r.
In this case, given
w: an old write to e.value
w1: e.value = value ( before count = c)
r: a read of e.value happening after the read of count in another thread
we know w HB w1 HB r, so r is not allowed to get the value of w, i.e. an
old write to e.value
Therefore, JMM does not allow such execution that "e.value = value" and
"count = c" are reordered and the old value of e.value can be read.
Am I correct? Thanks.
Regards,
Weijian
-------------------------------
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