Sylvia,
Thanks. It makes sense to me now, at least for the moment :-)
I do wonder if this makes volatile read/write more expensive
to execute than with the original memory model (however flawed
it might be).
Does anyone know how much, for example, a full read barrier at
volatile read costs compared with just fetching the one volatile
from main memory?
_____________________________________________________
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 Sylvia Else
> Sent: Friday, 14 November 2003 2:37 p.m.
> To: Java Memory Model
> Subject: RE: JavaMemoryModel: Question about implementation of
> java.util.concurrent.ConcurrentHashMap
>
>
> At 08:41 AM 14/11/2003, Evan Ireland wrote:
> >Jeremy,
> >
> >Suppose we have two statements executed by a thread:
> >
> > (1) x.f = a; (f is non-volatile, x is known not to be null)
> > (2) y.v = b; (v is volatile field, y is known not to be null)
> >
> >If statement (1) is executed before statement (2), then (1) hb (2),
> >and thereby any thread subsequently reading y.v should be certain of
> >seeing the modified value of x.f. I agree that this is implied by the
> >happens-before rules.
> >
> >However, if statement (2) is executed before statement (1), due to
> >reordering, then visibility of the modified value of x.f seems not
> >to be assured by the happens-before rules.
>
> The happens before rules are determined by the order in which the
> statements appear in the program. They are not affected by any reordering
> performed by the compiler or harware.
>
> Sylvia.
>
> -------------------------------
> 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