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 email@example.com +64 4 934-5856
Sybase EAServer Engineering, Wellington, New Zealand.
> -----Original Message-----
> From: firstname.lastname@example.org
> [mailto:email@example.com]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
> At 08:41 AM 14/11/2003, Evan Ireland wrote:
> >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.
> JavaMemoryModel mailing list -
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