Sylvia's response pointed out the same.
Do you think it would be worth clarifying this in the document,
or perhaps a FAQ or happens-before-for-dummies section?
Evan Ireland email@example.com +64 4 934-5856
Sybase EAServer Engineering, Wellington, New Zealand.
> -----Original Message-----
> From: Bill Pugh [mailto:firstname.lastname@example.org]
> Sent: Friday, 14 November 2003 4:27 p.m.
> To: email@example.com; Jeremy Manson
> Cc: Java Memory Model
> Subject: RE: JavaMemoryModel: Question about implementation of
> At 10:41 AM +1300 11/14/03, 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 difficulty I am having is that I can't find any language in the
> >community draft 2 JMM or JLS documents which specify that performing
> >statement (2) before statement (1) would violate intra-thread
> >semantics, thereby ( (1) hb (2) ) might not be true (in this case),
> >thereby visibility of non-volatile field changes made before volatile
> >write might not be certain (in the general case).
> (1) comes before (2) in program order. Therefore, (1) hb (2). No
> ordering transformations are allowed to change program order. Note
> that the program does not have to be executed in program order.
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