Rob Strom wrote:
> Did I misunderstand Figure 7 in the paper on page 10 of
> the OOPSLA proceedings?
>
> I understood that figure to say that a read of volatile v
> generates this after the loadL:
>
> fence_rr v, *VR
> fence_wr v, *R
Indeed. This translation doesn't really give any sort of meaningful
semantics... The correct translation transposes the sense of the last
barrier:
fence_wr *V, v
reconcile v
loadl v
fence_rr v, *VR
fence_rw v, *R
This is a typo which appears correctly in our slides and in our online
memo version of the paper
( ftp://csg-ftp.lcs.mit.edu/pub/papers/csgmemo/memo-428.ps.gz ).
I, too, would like to be able to assert that local barriers can be
eliminated with no observable effects. That requires a generalization
of CRF with multiple stores, in which Commit & Reconcile are enforced
separately for each store (and thus where we must observe the store to
see its effect on ordering). This is the G-CRF mentioned in the
paper. I've shied away from introducing it into discussion, though I
suspect we will need to do so once higher-level issues are ironed out.
The higher-level issue at hand, then: How *do* we create a reader lock
without relying on volatiles to create barriers (because I don't think
the final semantics should allow this trick)? In general, how many
ordering constraints do we think we need for volatile variables?
-Jan
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:28 EDT